no issue
We want to automatically show brand settings expanded in the design menu when the active theme has no custom theme settings, in order to do that without causing visual noise/jank we need to ensure that we have all the data we need up-front before the design menu is rendered.
- optimized `customThemeSettings` loading behaviour
- `.load()` will now only perform a fetch if settings have not previously been loaded so it can be called without causing unnecessary waits
- `.reload()` will force a clear+refetch of the settings - called by `themeManagement.activate()` after successfully changing a theme
- moved fetching of theme settings from the design menu constructor to the `settings.design` route's `model()` hook
- means the app will wait for loading to finish before showing any of the design settings screen so we can guarantee the data we need is available
- moved update of preview html from the design menu constructor to the design settings route as it's a more appropriate place to find screen setup/loading behaviour
refs https://github.com/TryGhost/Team/issues/1149
- `customThemeSettings.{settings,settingGroups}` are arrays with references to Ember Data model instances, those instances will automatically have updated properties on save so there's no need to completely re-build the settings and settingGroups lists that were forcing a re-render of the same data
refs https://github.com/TryGhost/Team/issues/1149
- `customThemeSettings.rollback()` was not performing the correct job, changed to rollback attributes on each model rather than resetting everything to empty
- moved leave confirmation handling to the `settings.design.index` route so that it's always called when moving to the change-theme route, previously with the behaviour on the main `settings.design` route the willtransition/deactivate was not called when expected because that route is still active when on `settings.design.change-theme`
no issue
- if there are no settings loaded then we shouldn't try to save an empty `custom-theme-setting-list` record because it will result in an invalid API request
refs f4596a0add
- when extracting the groups code from component to service some variable names were changed but the assignment was missed meaning we were assigning all settings rather than specific group settings to each `group.settings` array
no issue
- `get settingGroups()` was always returning a new object which meant the template was re-rendering unexpectedly which created issues with form fields that lose their focus when re-rendered
- moved group handling into the `customThemeSettings` service as it makes more sense to keep it centralized, that gave us the ability to create a new `settingGroups` array only when the settings list changes keeping the tracked invalidation easier to reason about
refs https://github.com/TryGhost/Team/issues/1111
- on saving, `customThemeSettings.settings` was set to the `hasMany` reference on the `customThemeSettingsList` model instance but the model is then immediately unloaded and the reference goes with it
- switched to using `.toArray()` on the hasMany so that we get a stable reference to the `customThemeSetting` model instances
no issue
- `customThemeSettings.settings` was not being updated with the latest models after saving so `customThemeSettings.isDirty` was still reporting `true` even though the save had completed
refs https://github.com/TryGhost/Team/issues/1097
- added `customThemeSettings.keyValueObject` which returns a plain object with setting values assign to the setting keys on the object
- updated customize modal's preview data generation to use `customThemeSettings.keyValueObject` to assign a JSON-stringified version to the `custom` param on the `x-ghost-preview` header
- updated theme settings `<Select>` component to call the passed through `updatePreview()` action when the value changes
refs https://github.com/TryGhost/Team/issues/1070
- split select form component into it's own component so it's cleaner when we get to additional setting types
- added change handler that updates the setting record's value when a new option is selected
- added `.isDirty` to the custom-theme-settings service so we can warn of unsaved changes and revert any changed values when needed
- added save of custom theme settings to the customize design modal's save routine
- added missing `notifications` service import to customize design controller
refs https://github.com/TryGhost/Team/issues/1070
- adds a `customThemeSettings` service that handles overall setting loading and saving to avoid components having to know any of the intricacies of the model setup
- adds `custom-theme-setting-list` model so that we can save multiple setting records as embedded relations
- custom adapter ensures requests go to the `/custom_theme_settings` base route as a `PUT` request
- custom serializer drops the default `models: []` wrapper in the save request data so the format matches the `PUT /settings` endpoint, then converts the response to look like a `custom-theme-setting-list` response
