no issue
Ember is migrating to `<AngleBracketSyntax />` for component invocation, see https://github.com/emberjs/rfcs/blob/master/text/0311-angle-bracket-invocation.md
We were in a half-way situation where some templates used angle bracket syntax in some places, this PR updates templates to use the syntax everywhere.
This simplifies the rules for what template code is referring to...
`<Component>` = a component
`{{helper}}` = a helper (or locally assigned handlebars variable)
`{{this.foo}}` = data on the template backing context (a component/controller)
`{{@foo}}` = a named argument passed into the component that the component backing class has not modified (note: this commit does not introduce any named arguments)
- ran codemod https://github.com/ember-codemods/ember-angle-brackets-codemod on the following directories:
- `app/templates`
- `lib/koenig-editor/addon/templates`
- removed positional params from components as angle bracket syntax does not support them
- `gh-feature-flag`
- `gh-tour-item`
- `gh-cm-editor`
- `gh-fullscreen-modal`
- `gh-task-button`
- updates some code that was missed in 3c851293c1 to use explicit this
no issue
- cleaned up the `deprecation-workflow.js` file by removing deprecations that are no longer being triggered by our test suite or general app usage (if they are still triggered in untested areas it will be useful to see the logs)
- updated usages of `{{gh-text-field}}` to use it's `shouldFocus` attribute rather than directly overriding it's `autofocus` computed property
no issue
We were in a part-way state where some touched files had been (sometimes partially) migrated to explicit `this`. The codemod that was available has now fixed the formatting issues it had so it was a good time to run it.
https://github.com/ember-codemods/ember-no-implicit-this-codemod
- part of the migration path for https://github.com/emberjs/rfcs/pull/308
- starts to make template resolution rules more explicit
- `<MyComponent />` - always a component
- `{{my-component}}` - component or helper (components _must_ have a `-`. This style of component will go away once fully migrated to angle bracket components)
- `{{value}}` - a helper or local template variable
- `{{this.value}}` - reference to a property on the backing context (either a controller or a component JS file)
closes https://github.com/TryGhost/Ghost/issues/9386
- remove usage of `{{one-way-checkbox}}` in favour of direct HTML+handlebars
- add `{{gh-text-input}}` that inherits from Ember's built-in `TextInput` component along with our custom `TextInput` mixin
- swap all uses of `{{gh-input}}` for `{{gh-text-input}}
- remove `{{gh-input}}` component
- update `{{gh-textarea}}` to inherit from Ember's `TextArea` component instead of `OneWayTextarea` and update all component uses accordingly
- update `{{gh-trim-focus-input}}` to inherit from `{{gh-text-input}}` and update all component uses accordingly
- standardize on using the `focus-out` action naming rather than `focusOut` for all text inputs, this is because the text input components (especially `{{gh-trim-focus-input}}`) have their own `focusOut` handler which gets overridden if consumers supply their own `focusOut` attr
- drop `ember-one-way-controls` package
- add `ember-one-way-select` package
no issue
- if we would like to re-add html in our error messages, we have to differentiate between static messages which can contain html and messages which are dynamic and can contain dynamic input, which should not allow html
- e.g. it is always possible that Ghost receives a message from a third party module, which concats static text with input text
- if we want to show html content from an error, we need to come up with a concept
- for now: no support for html in error messages
refs https://github.com/TryGhost/Ghost/issues/7515
- changes to `gh-task-button`:
- can take `buttonText` (default: "Save"), `runningText` ("Saving"), `successText` ("Saved"), and `failureText` ("Retry") params
- positional param for `buttonText`
- default button display can be overridden by passing in a block, in that scenario the component will yield a hash containing all states to be used in this fashion:
```
{{#gh-task-button task=myTask as |task|}}
{{if task.isIdle "Save me"}}
{{if task.isRunning "Saving"}}
{{if task.isSuccess "Thank you!"}}
{{if task.isFailure "Nooooooo!"}}
{{/gh-task-button}}
```
- update existing uses of `gh-task-button` to match new component signature
ref #5652
- validations can be in default, success or error state
- adds check for 'hasValidated' if the validations haven't fired yet, the field is in the default state
- hasValidated is an Ember.Array which tracks the state for each field
refs #5652
- always put button text inside opening/closing helper tag
- only include type if it is 'submit' as button is default
- wrap attributes in double quotes
No Issue
- Takes the inline validation messages and displays below form
- Removes unnecessary gh-error-message components from signin and reset pages
- Returns error messages to sign-in validations