Skip to content
This repository has been archived by the owner on Mar 22, 2019. It is now read-only.

[WIP] Adds Module Unification & Octane Update blog post #3848

Merged
merged 7 commits into from
Mar 11, 2019

Conversation

tomdale
Copy link
Member

@tomdale tomdale commented Mar 2, 2019

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

giphy

@locks locks temporarily deployed to ember-website-staging-pr-3848 March 2, 2019 07:08 Inactive
@locks locks temporarily deployed to ember-website-staging-pr-3848 March 2, 2019 07:19 Inactive
Copy link
Contributor

@acorncom acorncom left a 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 ...

@jenweber
Copy link
Contributor

jenweber commented Mar 2, 2019

To resolve the test errors, add the words to the .alexignore file

@jenweber
Copy link
Contributor

jenweber commented Mar 2, 2019

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
experiences my co-workers had had when using MU.
experiences my co-workers had when using MU.

Copy link
Member Author

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.

@locks locks temporarily deployed to ember-website-staging-pr-3848 March 4, 2019 02:32 Inactive
@amyrlam amyrlam mentioned this pull request Mar 4, 2019
16 tasks
Copy link
Contributor

@MelSumner MelSumner left a 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.

@locks locks temporarily deployed to ember-website-staging-pr-3848 March 7, 2019 22:44 Inactive
@locks locks temporarily deployed to ember-website-staging-pr-3848 March 9, 2019 01:35 Inactive
@MelSumner MelSumner dismissed their stale review March 9, 2019 01:38

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.
Copy link
Member

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:
Copy link
Member

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}}
```
Copy link
Member

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}}
```
Copy link
Member

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.
Copy link
Member

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' }
Copy link
Member

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:
Copy link
Member

@chancancode chancancode Mar 9, 2019

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 and UserIcon— 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
Copy link
Member

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

@mansona
Copy link
Member

mansona commented Mar 11, 2019

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 😂

@rwjblue rwjblue merged commit 7df3581 into master Mar 11, 2019
@rwjblue rwjblue deleted the mu-octane-update branch March 11, 2019 22:31
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants