Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUEST] Octane #1117

Closed
5 tasks
betocantu93 opened this issue Nov 12, 2019 · 12 comments
Closed
5 tasks

[QUEST] Octane #1117

betocantu93 opened this issue Nov 12, 2019 · 12 comments

Comments

@betocantu93
Copy link
Contributor

betocantu93 commented Nov 12, 2019

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

@v3ss0n
Copy link

v3ss0n commented Nov 14, 2019

are you an octane main?

@betocantu93
Copy link
Contributor Author

@v3ss0n I don't know what that means

@lolmaus
Copy link

lolmaus commented Jan 4, 2020

Why is this closed?

@betocantu93
Copy link
Contributor Author

@lolmaus the initiative didn't got any feedback by the community, but let's update the scope and reopen, see how it goes

@betocantu93 betocantu93 reopened this Jan 5, 2020
@lolmaus
Copy link

lolmaus commented Jan 5, 2020

@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.

@miguelcobain
Copy link
Collaborator

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 fn helper instead of action
  • 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.

@betocantu93
Copy link
Contributor Author

@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?

@miguelcobain
Copy link
Collaborator

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
}

@larryh
Copy link

larryh commented Jan 23, 2020

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!

@miguelcobain
Copy link
Collaborator

miguelcobain commented Feb 7, 2020

Released 1.0.0-beta.27 and took the chance to migrate the RippleMixin to a <PaperRipple/> component. One less Mixin to deal with.

@devotox
Copy link
Contributor

devotox commented Feb 7, 2020

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.

@Subtletree
Copy link
Collaborator

Subtletree commented Mar 3, 2022

New tracking issue: #1213

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants