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

Ember to vue #14

Merged
merged 5 commits into from Aug 6, 2019
Merged

Ember to vue #14

merged 5 commits into from Aug 6, 2019

Conversation

@sbatson5
Copy link
Owner

@sbatson5 sbatson5 commented Aug 3, 2019

Description

A blog post about going from Ember to Vue!

Copy link

@NullVoxPopuli NullVoxPopuli left a comment

Left some comments. This is lookin' good 👍

Loading

Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
## Components are one file

I found this weird at first, but boy, do I like components with both markup and JavaScript in the same file.
I hated having to bounce between files so often in Ember (especially when the community wanted to move away from pod structure).

Choose a reason for hiding this comment

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

Single File Components are coming in Ember, too emberjs/rfcs#454

Ember kinda likes to steal all the good ideas from all the other ecosystems.

But yeah, the classic structure is pretty terrible for jumping between related files. It's being worked on (just lots of primitives to implement first befare it'll be easy to migrate to)

Loading


I've actually heard this complaint a few times about "I don't like JS/HTML/CSS in the same file because I like separation of concerns."
I get the sentiment, but to be clear, just because "concerns" are in the same file, doesn't mean they aren't separated.
The JavaScript of a component is too tightly tied to the markup (as it should be), so why force yourself to bounce between the two files?

Choose a reason for hiding this comment

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

the pattern is actually handy in react -- where you have a "smart" component (js), and a "dump component" (template). It's handy when your component does a lot of things

Loading

content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
Loading
export default router;
```

Much like react-router, we specify the route name and point it to a component that we have imported (here, we store them in a `routes/index.js` file, but they could live anywhere).

Choose a reason for hiding this comment

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

how does this affect async loading / route-splitting?

Loading

Choose a reason for hiding this comment

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

@sbatson5 can vue do route splitting?

Loading

Copy link

@lowski lowski Aug 5, 2019

Choose a reason for hiding this comment

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

Loading

content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
@sbatson5
Copy link
Owner Author

@sbatson5 sbatson5 commented Aug 3, 2019

@NullVoxPopuli Thank you so much for the feedback!

Loading

Copy link

@snewcomer snewcomer left a comment

Very nice post. Pleasure reading it! I'm rather naive on Vue, so just a few questions an outsider would love to learn about.

Loading


## Components

Components in Vue are more similar to Ember than the ones in React.
Copy link

@snewcomer snewcomer Aug 3, 2019

Choose a reason for hiding this comment

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

Is there a difference under the hood? Glimmer with binary format + eliminating parse step vs not sure what is on Vue's side.

Loading

Copy link

@locks locks Aug 5, 2019

Choose a reason for hiding this comment

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

What binary format?

Loading

content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
When you create a route, you are pointing to a component.
There is literally nothing special about this component -- it can be literally any component that you want (in fact, you can use it both as a route _and_ component on the page... although, you really shouldn't).

In my opinion, this is a good habit to get into as it will help you transition to something like React down the line if you have to.

Choose a reason for hiding this comment

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

what about testing? Would be curious on the testing apparatus and how you like it :)

Loading

Copy link
Owner Author

@sbatson5 sbatson5 Aug 3, 2019

Choose a reason for hiding this comment

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

I went back and forth on whether to include testing stuff, but that's a whole blog post in itself.

Much like routing and state management, it doesn't come out of the box but there is an officially supported solution:
https://vue-test-utils.vuejs.org/guides/getting-started.html
Using Jest as the test runner is what I've seen most, but you can use mocha as well.

From what I've done, it's very specific component-level testing. I haven't really done Acceptance level testing in a project yet

Loading

Choose a reason for hiding this comment

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

Does the Vue community encourage testing against a real browser? I think the jest default is jsdom, which is all fake, and users don't use fake browsers.

Loading

Copy link

@lowski lowski Aug 5, 2019

Choose a reason for hiding this comment

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

I hope it's gonna be even better since mirage is being extracted from ember-cli-mirage

Loading

Copy link
Owner Author

@sbatson5 sbatson5 Aug 6, 2019

Choose a reason for hiding this comment

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

Does the Vue community encourage testing against a real browser? I think the jest default is jsdom, which is all fake, and users don't use fake browsers.

From what I have seen so far, most of the documentation and examples are with jest and not real browser testing. That being said, I've only worked on 3 Vue apps with very similar approaches, so I'm sure examples exists somewhere.

Loading

You could do `import SomeCustomComponent as Monkey from '@something/components';` and rename a component without any magic.
This saves you from potential name collision, as an npm package might have a component with the same name yours.
You could do `import SomeCustomComponent as Monkey from '@something/components';` and rename a component easily.
Again, this is something in an RFC for Ember already but it cements a point I made in an earlier post that [the resolver is a bit too clever sometimes](/posts/a-few-thoughts-on-ember/#3-make-the-resolver-less-clever).

Choose a reason for hiding this comment

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

:) this is a WIP!

it's actually a primary motivator behind why module unification hadn't/hasn't happened -- too much resolver logic.

Loading

`methods` are the equivalent of `actions` in Ember -- if there is a function that is going to be called from the template, it is in the `methods` hash.
Functions can live outside of that hash (obviously) but this tells you what you expect to interact with your markup.

Choose a reason for hiding this comment

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

this is handy -- ember on the other hand has moved away from this, because people just want to use functions on the class -- it's super nice -- only mishap you can run in to is when you accidentally name an action the same an a component API -- with Ember Components, that's a lot more likely than in Octane's Glimmer Components (Ember has like.. 30+ apis, and Glimmer has 4)

Loading

If the user triggers that action, however, I will get an error like `this.updateProfile is not a function` (or something similar).
So, you wrap stuff in if conditions to make sure that's not the case.

With emitting, the child component won't hit this error, as all it does is emit something out and it's up to the parent to intercept it.

Choose a reason for hiding this comment

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

what if you want to be told that you are using an incorrect function? how do you debug this?
it sounds like it just fails silently, and if you don't have tests over this particular area, you won't know that you maybe have a typo or something

Loading

Copy link
Owner Author

@sbatson5 sbatson5 Aug 6, 2019

Choose a reason for hiding this comment

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

You can still pass functions as props to a child component (although it is usually a sign that you might be doing something wrong): https://michaelnthiessen.com/pass-function-as-prop/

For a child component communicating something up, I'd say that failing silently is fine. A component can continue to function even if the right event isn't triggered up the chain.

Loading

Choose a reason for hiding this comment

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

I'd say that failing silently is fine.

wouldn't that be hard on maintenance? how would you track things down? like, if you're expecting a parent component or something to react to something that was emitted?

Loading

Copy link
Owner Author

@sbatson5 sbatson5 Aug 6, 2019

Choose a reason for hiding this comment

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

If you have a parent that is truly dependent on an update triggered by a child, I think that should be handled in Vuex. The child can dispatch an event to the store, which triggers a mutation, updates our application state and the parent can observe that.

Emitting is better for non-state specific logic. I.e. I click a button in my ButtonComponent and my parent component updates the background color. That doesn't need to live at the application-state level. The child just says "Hey, I'm clicking the button!" and it shouldn't break just because the parent didn't know how to respond to it. The child should continue to function.

Loading

Choose a reason for hiding this comment

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

gotchya -- so your solution to that, is pretty similar redux (as I think you've said elsewhere).

this is bringing up so many frontend data-flow philosophy things. I need to figure out how to organize my thoughts about this and right a blog post on it. :)

Loading

Copy link

@locks locks left a comment

Did a quick pass on the text and the current discussions :)

Loading

content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading

## Components

Components in Vue are more similar to Ember than the ones in React.
Copy link

@locks locks Aug 5, 2019

Choose a reason for hiding this comment

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

What binary format?

Loading

content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
content/posts/2019-08-03---Going-from-ember-to-vue.md Outdated Show resolved Hide resolved
Loading
NullVoxPopuli
Copy link

NullVoxPopuli commented on 561b058 Aug 6, 2019

Choose a reason for hiding this comment

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

🔥 🔥 🔥 🔥 🔥 🔥 :)

Loading

@sbatson5 sbatson5 merged commit 6cbdda0 into master Aug 6, 2019
6 checks passed
Loading
@sbatson5 sbatson5 deleted the ember-to-vue branch Aug 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants