3 ms·
Most of this is simply incorrect. Declaring properties at runtime is an antipattern. You never need to use function() Props and state are absolutely not mixe
by CaveTech 9y ago
Most of this is simply incorrect.
Declaring properties at runtime is an antipattern.
You never need to use function()
Props and state are absolutely not mixed. Props are inherited and immutable by default.
Content editable doesn’t fit in with the vue paradigm but you can easily abstract that section out of vuejs. If you dom is not dictated by your data, then a render function makes little sense.
- joshribakoff 9y ago> Declaring properties at runtime is an antipattern. That's a pretty bold statement & I won't argue, but either way that's an opinionated decision of the framework. React is less opinionated & doesn't care what you use for your state. Vuejs is opinionated, they don't care about working well with Redux or other state management libraries because they already have their own, Vuex, which is pretty nice for the most part. > Props and state are absolutely not mixed a prop called "foo" & data/state param called "foo" are both accessed at this.foo, its no longer obvious what would happen if I would try to mutate this.foo. It mutates the data/state, not the prop, so now this.foo refers to the value in the data/state, which has a different value from the prop "foo" which can no longer be accessed at this.foo > You never need to use function() See this page which says "Don’t use arrow functions ": https://vuejs.org/v2/guide/instance.html#Data-and-Methods https://vuejs.org/v2/guide/instance.html#Data-and-Methods > you can easily abstract that section out of vuejs. Yeah you can, by not using vuejs. React has escape hatches to get out of your way, so you could continue to use it in that scenario thats part of why im switching back from vuejs to react.
- CaveTech 9y ago> a prop called "foo" & data/state param called "foo" are both accessed at this.foo, its no longer obvious what would happen if I would try to mutate this.foo. It mutates the data/state, not the prop, so now this.foo refers to the value in the data/state, which has a different value from the prop "foo" which can no longer be accessed at this.foo Well yes, but have props and state with the same name is again just code smell. > See this page which says "Don’t use arrow functions ": This is a very narrow restriction and pretty obvious why you shouldn't do it, ie it passes a context that makes no sense. This is not a Vue limitation. > React has escape hatches to get out of your way So does Vue, don't use the Vue `render` if Vue isn't managing the state.
- joshribakoff 9y agoHey you quoted my point about escape hatches but forgot to respond, interested to hear your thoughts. I guess to the 1st point, yes and Vue js allows this smell while React doesn't. Regarding 2nd point, I disagree it's narrow, it affects all methods for all components. But its not a big factor in deciding what framework to use. React is just a tad more "standards compliant" when it comes to web development, in my opinion. And in web development standards matter a lot, even when the standards themselves may not be great... I really like VueJS for what its worth, its still my favorite framework, but I'd bet my money on React in the same sense I would invest in Walmart even though its not the perfect business. The react ecosystem has a much higher learning curve also, to play devils advocate.
- CaveTech 9y agoSorry I responded but I forgot the newline. In either case react is clearly the better ecosystem, but vue is a really, really solid framework itself. We’ve hit our own limitations that we’ve had to work around, but imo most of the points you bring up have quite simple fixes. Cheers!