Meeting: Ember Core Team - Aug 09, 2019
- Determine note taker - JW and CG
- Template only components generated by default (JW/GC)
- An example so we're all on the same page (see also the RFC)
- When would we aim to land it?
- What is the rationale for the default?
- What side effects would it have?
- Next steps?
- Feedback on
- Feedback on @model RFC (GC)
- Roadmap RFC (TD)
- → FCP
- FCP → Merge
- → FCP to Close
- FCP to Close → Close
- Jen uploads notes
YK: I have to leave at half past, can we prioritize the items that I'm needed for?
... discussion on order of agenda...
YK: I will commit to having the blog post out.
YK: Did you see the slide deck Mel put together?
TD: make sure to sell the state of the art, the best you can get, with tracked properties. Avoid saying that "we finally caught up" - driving innovation
DG: frame in terms of reactivity model that we think is state of the art and very general
TD: emphasize html aspects & the fun of it
TO-components generated by default
JW: I've been discussing the TO-components by default generators with the learning team and there were some concerns raised. Some people like the approach and others saw some pitfalls.
GC: you don't have to use the generator as much now. I show making the file by hand in the tutorial. People have the ability to customize generators now too
YK: seems plausible that people will make files by hand given current IDE trends and how simple what you generate would be. A VSCode plugin could accomplish the same, could be an editor extension
RJ: the editor would use those commands behind the scenes
DG: we want to avoid people feeling thrashed about when it comes to possible SFC of the future
GC: SFC is a big shift no matter what
TD: A couple people in chat have asked, the status quo is that we generate js and hbs. People have asked if we can make template only the default for later. Can you share more about this?
YK: is it simple?
GC: I really wanted this to be part of Octane bc it is part of the teaching shift. I am working as hard as I can to get this ready in time and committed to this in the past. I have been making the files by hand in the tutorial
TD: Why not make all files by hand
YK: we could make ember g component-class to make the class
TD: are you open to introducing a component-class command?
GC: yes, as long as we are not changing the other default
CG: it's a parallel with ember g component-test
RJ: a component is two things, a template and possibly also a class
(discussion of UX)
MS: People expect Ember to give them the files that they need, and this is different
TD: Part of the issue is we just don't know how often people will need these JS files
Options for helping people learn/discover generator changes:
- VSCode extension could fill in the class. It could use the commands
- Need a lint rule for deeply nested hbs/complexity
- Could provide ember generate component-class command
- Make it clear in the Guides
- Could have a template generated by the component generator that has a note in it
- Could show a message in the CLI after generating the file
- Could make it so that the "do you want to override this file" message is suppressed when you run a component generator a second time
GC: It helps to look over what's in the tutorial and I'm making more progress on this
JW/TD: we'll look it over and write up the plan on Tuesday, if not before
TD: any objections to FCP?