-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[WIP] Adds Module Unification & Octane Update blog post #3848
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work on thought-leadering here ...
To resolve the test errors, add the words to the .alexignore file |
This was a great read! Thanks for writing. |
So this was the status quo last year. We were all incredibly frustrated that | ||
we couldn't make progress on the scoped package problem, but I was even more | ||
overwhelmed trying to figure out what, if anything, to do about the negative | ||
experiences my co-workers had had when using MU. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
experiences my co-workers had had when using MU. | |
experiences my co-workers had when using MU. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually grammatically correct: it's past perfect tense, plus the past participle of have.
For example, this sentence in the present perfect:
They have had a bad experience today.
Becomes this sentence in the past perfect:
They had had a bad experience yesterday.
source/blog/2019-03-02-update-on-module-unification-and-octane.md
Outdated
Show resolved
Hide resolved
source/blog/2019-03-02-update-on-module-unification-and-octane.md
Outdated
Show resolved
Hide resolved
source/blog/2019-03-02-update-on-module-unification-and-octane.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After more team discussion, we need a little more conversation before this posts.
Co-Authored-By: rwjblue <[email protected]>
The FW core team had the necessary conversations to move this forward.
|
||
This co-located `component.js` and `template.hbs` layout actually already | ||
works in Ember apps today, so the only change required is to update the | ||
default component blueprint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will also provide a codemod...
|
||
For example, if you have a component located at | ||
`app/components/icons/download-icon.js` (i.e., nested inside an `icons` | ||
directory), you can invoke it with curly invocation syntax like this: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mayybee add "(or app/components/icons/download-icon/{component.js,template.hbs}
when co-located)"
{{#ember-ui-library::small-button}} | ||
... | ||
{{/ember-ui-library::small-button}} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would probably just skip this, since scoped packages is a much bigger problem, and this draws some attention to "doesn't nested components above have the same issue?". (IMO, not really, but still.)
{{#@my-company/ember-ui-library::small-button}} | ||
... | ||
{{/@my-company/ember-ui-library::small-button}} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe: on top of that, @
usually mean named arguments, overloading that sigil here is too uncanny.
|
||
Additionally, named imports (`import { thing }`) and wildcard imports | ||
(`import *`) didn't really translate either, given the template/class split. | ||
Another deviation from JavaScript. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite get it (the problem being described in this paragraph).
import UserIcon from './icons/user'; | ||
|
||
export class BlogPost extends Component { | ||
blog = { title: 'Coming soon in Octane', authorId: '1234' } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lint: ASI violation, insert semi colon here 😄
low-level primitives, not the API that would be used by Ember developers to | ||
author templates. | ||
|
||
Here is one example of a **very hypothetical** template imports syntax: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I would still prefer to see the "purest" form of template imports (strawman syntax is the ---
one) that does not mix with JS, before showing the full SFC example:
Here is one example of a very hypothetical template imports syntax:
--- import UserProfile from './user-profile'; import UserIcon from './icons/user'; --- <h1>{{this.blog.title}}</h1> <UserIcon /> <UserProfile @userId={{this.blog.authorId}} />The syntax is up in the air and will almost certainly be different from
this example. Regardless, it shows the benefit of template imports clearly:
we've imported two components—UserProfile
andUserIcon
— just like
how we would refer to any other JavaScript module. This makes it very easy
for everyone— from developer who are new to Ember, to IDEs, and other
tooling in the JavaScript ecosystem`— to understand what came from where.You can even imagine a (again, very hypothetical) single-file component
format that places the template right within the component's class. Here, a
unified imports solution feels especially natural:// src/ui/components/blog-post.gbs import Component from '@glimmer/component'; import UserIcon from './icons/user'; export class BlogPost extends Component { blog = { title: 'Coming soon in Octane', authorId: '1234' }; <template> <h1>{{this.blog.title}}</h1> <UserIcon /> <UserProfile @userId={{this.blog.authorId}} /> </template> }Again, the exact syntax is up in the air and will almost certainly be different
from this example. The benefit of exposing the low-level primitives first is that
we can try out multiple competing designs relatively easily before comitting.
And if you don't like what we eventually decide on, you can build an
alternative that is just as stable as the default implementation....
My personal syntactic preference/reservations aside, I genuienly think this separation/staging makes it much more easier to understand what is being talked about here, especially for most Ember developers who have not seen any of these yet. I mostly just copy and pasted your wording, which made it a bit repetitive, so feel free to edit it down.
* `app/components/user-profile/template.hbs` | ||
* `tests/integration/components/user-profile-test.js` | ||
|
||
This co-located `component.js` and `template.hbs` layout actually already |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI - This support was added in ember-cli/ember-resolver#61 waaaaaaaaay back in 2014...
Hey folks 👋 I know there is a lot of back and forth still on this blog but you may notice once it gets merged that it won't automatically get deployed. This is essentially the last blog that will go live from the old infrastructure so once this PR is merged I will do the necessary steps to port it to the new infra 👍 I won't do anything until this PR is merged and once it is I will take that as the intention that you want it live 😂 |
What it does
Provides thoughtleadership to the Ember community in the form of a weblog ("blog") post, describing the status of Module Unification and the plan for Octane.
Related Issue(s)
Sources