4 ms·

I'm switching from Vue to React because I find it really kludgy to have to call Vue.set to declare new reactive properties at runtime. Its also a bit nicer in

I'm switching from Vue to React because I find it really kludgy to have to call Vue.set to declare new reactive properties at runtime. Its also a bit nicer in that React tends to follow ES standards like ES6 classes for components, instead of exporting a POJO for your component. In vue you often have to use function() instead of fat arrow syntax because of the context of "this". With react you used to have lots of .bind(this) boilerplate, but now we have shorthand property syntax. Vue also mixes props & state, where as React keeps them separate. React implements certain lifecycle methods like componentShouldUpdate() whereas Vue doesn't because the creator thinks it would complicate the API, meanwhile there's known issues like between Vue.js & HTML5 content editable due to this lack of lifecycle method. Vue is easier to get going & much faster to develop in initially, lower learning curve, and friendlier API.

AlfeG 9y ago
> I'm switching from Vue to React because I find it really kludgy to have to call Vue.set to declare new reactive properties at runtime. Why You need to do this that often? We have a lot of moving parts in app, but just a few `Vue.set` calls.
truetuna 9y ago
Could you expand a bit on shorthand property syntax or provide a link to somewhere I could read more? I'm still doing a lot of .bind(this) in many places and I'm looking for an alternative.
- eschutte2 9y ago
  https://babeljs.io/docs/plugins/transform-class-properties/ https://babeljs.io/docs/plugins/transform-class-properties/ https://www.fullstackreact.com/articles/use-property-initializers-for-cleaner-react-components/ https://www.fullstackreact.com/articles/use-property-initial...
  - lwansbrough 9y ago
    Isn't `something = () => {}` just a property declared as an anonymous function? Or is there more going on under the hood? At first glance this looks like a poor choice for debugging purposes.
    - joshribakoff 9y ago
      well the alternatives I know of were to call .bind(this) all over the place, or wrap your handlers in a fat arrow wrapper function which is also an anonymous function as you say. I think this is the nicer of the options, and Vue.js is similar but you provide a hash of functions keyed by name, which is basically the same thing just different syntax. This nice thing about React is it doesn't matter. You can just write functional components if you don't want the es6 class stuff.
    - eschutte2 9y ago
      The important thing is that the ES7 property initializer with the arrow syntax binds the function's "this" to the instance.
      - lwansbrough 9y ago
        I understand that, but that’s not necessarily acceptable if it makes debugging a nightmare. Apparently there is also a bind decorator, which I think is nicer than either of the other methods, because it is explicit but also clear, and without the verbosity.
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.

AlfeG 9y ago

> I'm switching from Vue to React because I find it really kludgy to have to call Vue.set to declare new reactive properties at runtime. Why You need to do this that often? We have a lot of moving parts in app, but just a few `Vue.set` calls.

truetuna 9y ago

Could you expand a bit on shorthand property syntax or provide a link to somewhere I could read more? I'm still doing a lot of .bind(this) in many places and I'm looking for an alternative.

eschutte2 9y ago
https://babeljs.io/docs/plugins/transform-class-properties/ https://babeljs.io/docs/plugins/transform-class-properties/ https://www.fullstackreact.com/articles/use-property-initializers-for-cleaner-react-components/ https://www.fullstackreact.com/articles/use-property-initial...
- lwansbrough 9y ago
  Isn't `something = () => {}` just a property declared as an anonymous function? Or is there more going on under the hood? At first glance this looks like a poor choice for debugging purposes.
  - joshribakoff 9y ago
    well the alternatives I know of were to call .bind(this) all over the place, or wrap your handlers in a fat arrow wrapper function which is also an anonymous function as you say. I think this is the nicer of the options, and Vue.js is similar but you provide a hash of functions keyed by name, which is basically the same thing just different syntax. This nice thing about React is it doesn't matter. You can just write functional components if you don't want the es6 class stuff.
  - eschutte2 9y ago
    The important thing is that the ES7 property initializer with the arrow syntax binds the function's "this" to the instance.
    - lwansbrough 9y ago
      I understand that, but that’s not necessarily acceptable if it makes debugging a nightmare. Apparently there is also a bind decorator, which I think is nicer than either of the other methods, because it is explicit but also clear, and without the verbosity.

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.