Ember to vue #14
Ember to vue #14
Conversation
| ## 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). |
There was a problem hiding this comment.
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)
|
|
||
| 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? |
There was a problem hiding this comment.
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
| 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). |
There was a problem hiding this comment.
how does this affect async loading / route-splitting?
There was a problem hiding this comment.
@sbatson5 can vue do route splitting?
There was a problem hiding this comment.
|
@NullVoxPopuli Thank you so much for the feedback! |
|
|
||
| ## Components | ||
|
|
||
| Components in Vue are more similar to Ember than the ones in React. |
There was a problem hiding this comment.
Is there a difference under the hood? Glimmer with binary format + eliminating parse step vs not sure what is on Vue's side.
| 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. |
There was a problem hiding this comment.
what about testing? Would be curious on the testing apparatus and how you like it :)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I hope it's gonna be even better since mirage is being extracted from ember-cli-mirage
There was a problem hiding this comment.
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.
| 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). |
There was a problem hiding this comment.
:) this is a WIP!
it's actually a primary motivator behind why module unification hadn't/hasn't happened -- too much resolver logic.
| `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. |
There was a problem hiding this comment.
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)
| 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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. :)
|
|
||
| ## Components | ||
|
|
||
| Components in Vue are more similar to Ember than the ones in React. |
Description
A blog post about going from Ember to Vue!