[QUEST] Octane
betocantu93 opened this issue · comments
Hello, happy new year, the Octane year. Here's a list of todos to bring Octane to this add-on.
- Deploy the website, there are some updates pending to be live
- Update Documentation to angle brackets
- Upgrade project to 3.16
- Upgrade index.js file for new components structure for whitelist / blacklist
- Refactor possible classic components to glimmer-components, template-only, etc...
Related issues
are you an octane main?
@v3ss0n I don't know what that means
Why is this closed?
@lolmaus the initiative didn't got any feedback by the community, but let's update the scope and reopen, see how it goes
@betocantu93 The issue is absolutely legit.
I believe, it is inevitable that Ember Paper will be eventually upgraded to Octane, refactored to angle brackets, etc. So it makes perfect sense to have a ticket to track progress.
That said, acknowledgement from addon maintainers would be really nice.
As the project's maintainer, I fully acknowledge this refactor.
In fact, I already started some work towards this direction on master.
paper-menu, paper-select, paper-autocomplete, paper-chips and paper-contact-chips were rebuilt from scratch using the latest ebd and eps versions.
I think we shouldn't go for glimmer components just yet.
There is a good stepping stone before that that I would like to suggest we aim for:
- always use tagless components. This way it will be very easy to migrate to glimmer components
- use native class syntax
- use on modifier instead of component event methods and
onclick={{action - use
fnhelper instead ofaction - always use
{{this.prop}}and{{@arg}}in templates - use decorators
- group the component.js and template.hbs in the same folder inside addon folder
- update documentation and tests to use angle bracket invocations
- avoid mixins where possible
If anyone wants to PR a refactor of a component, please do so.
Feedback is welcome.
@miguelcobain Great! sounds like a plan. I'll try to get some componets with native classes, decorators and modern templates, and update according tests and doc.
How would you like to handle avoiding mixins? class decorator? or just utils?
How would you like to handle avoiding mixins? class decorator? or just utils?
It depends. For example, we use the transition mixin (coming from ember-css-transitions).
I recently released v1 of ember-css-transitions that basically replaces the mixin with a very intuitive modifier.
It's an example of where a new well thought out ember primitive completely changed how that addon looks. :)
Ember paper should use latest version of ember-css-transitions and use that modifier, completely replacing the mixin.
Other examples like the ColorMixin and FocusableMixin I think can be easily replaceable by directly setting the correct classes in the components themselves.
The ValidationMixin probably requires some more thought as it is more complex.
The Translate3dMixin is very similar to the TransitionMixin and so it can be a modifier as well.
The RippleMixin I think can be migrated to a component. It would make ripples much more composable. Imagine having a <PaperRipple/> component that you could use anywhere. This component would attach to click handlers of the parent component by default.
A modifier could also work e.g <div {{paper-ripple}}>.
We don't need to migrate away from mixins all at once. We can use this approach if migrating away from some mixin isn't practical at the moment:
class PaperComponent extends Component.extends(Mixin) {
// class body
}
That is good news to hear. I use ember paper and think it is pretty gosh darn amazing - thanks to all of you who work on it!
Released 1.0.0-beta.27 and took the chance to migrate the RippleMixin to a <PaperRipple/> component. One less Mixin to deal with.
You can hit a lot of points using Ember CLI Update Codemods especially to do with the change to Angle Brackets. Then template linting can point you to where things like @ or this need to be used.
New tracking issue: #1213