no issue
The `settings` service has been a source of confusion when writing with modern Ember patterns because it's use of the deprecated `ProxyMixin` forced all property access/setting to go via `.get()` and `.set()` whereas the rest of the system has mostly (there are a few other uses of ProxyObjects remaining) eliminated the use of the non-native get/set methods.
- removed use of `ProxyMixin` in the `settings` service by grabbing the attributes off the setting model after fetching and using `Object.defineProperty()` to add native getters/setters that pass through to the model's getters/setters. Ember's autotracking automatically works across the native getters/setters so we can then use the service as if it was any other native object
- updated all code to use `settings.{attrName}` directly for getting/setting instead of `.get()` and `.set()`
- removed use of observer in the `customViews` service because it was being set up before the native properties had been added on the settings service meaning autotracking wasn't able to set up properly
refs https://github.com/TryGhost/Ghost/issues/14101
refs https://github.com/TryGhost/Admin/pull/2256
Before migrating to native classes we had a number of controllers/components that had an `.actions.foo` action and a `.foo` task. The automated migration to native classes didn't take that into account and we've ended up with duplicate top-level property names. These duplicates are confusing and can potentially lead to errors or unexpected behaviour, they'll also be flagged as linter errors when we bump our eslint version.
- switched tasks with matching action names to `.actionTask` naming scheme
no issue
- ran [ember-native-class-codemod](https://github.com/ember-codemods/ember-native-class-codemod) to convert the majority of remaining EmberObject based controllers and components to native class syntax using the `@classic` decorator
- skipped older style modal components (`components/modal-*.js`) due to observed incompatibilities in some cases
no issue
Updated settings navigation to a completely redesigned flow for Ghost 4.0 🎉
Co-authored-by: Kevin Ansfield <kevin@lookingsideways.co.uk>
Co-authored-by: Fabien O'Carroll <fabien@allou.is>
Co-authored-by: Rish <zrishabhgarg@gmail.com>
no issue
- fixed `<GhTaskButton>` not resetting after an externally triggered task run such as when pressing Cmd+S
- cleaned up manual timeouts/resets where button reset is now fully handled by `<GhTaskButton>` (these were causing 2.5s waits each time a save occurred in acceptance tests)
- where manual timeouts were required, reduce testing time from >2.5s to 50ms
* Updated save buttons to reset state
no issue
Currently the save buttons across Admin don't auto-reset to idle state after success/failure on run which can give false impression once user changes any value. This PR auto-resets the button to idle state after a fixed timeout if no subsequent action is performed as a short term UX improvement.
* Fixed success check for auto reset
* Updated timeout value
* Added explicit save button reset for pages
* Updated save buttons to reset via shortcut
Auto-reset for save buttons wasn't working if not done through manual click on task button previously, this handles by splitting the original save task in controller to handle shortcut saves.
* Updated reset check for only successful tasks
* Added save reset to code-injection and design settings
Co-authored-by: Peter Zimon <peter.zimon@gmail.com>
no issue
- ran [es5-getter-ember-codemod](https://github.com/rondale-sc/es5-getter-ember-codemod)
- [es5 getters RFC](https://github.com/emberjs/rfcs/blob/master/text/0281-es5-getters.md)
- updates the majority of `object.get('property')` with `object.property` with exceptions:
- `.get('nested.property')` - it's not possible to determine if this is relying on "safe" path chaining for when `nested` doesn't exist
- `.get('config.x')` and `.get('settings.x')` - both our `config` and `settings` services are proxy objects which do not support es5 getters
- this PR is not exhaustive, there are still a number of places where `.get('service.foo')` and similar could be replaced but it gets us a long way there in a quick and automated fashion
