7 ms·

Smart and dumb components are one of the reasons why I quickly jumped ship to Vue. It's too complicated and the starter apps make it worse. You get four level d

Smart and dumb components are one of the reasons why I quickly jumped ship to Vue. It's too complicated and the starter apps make it worse. You get four level deep directory structures where each dir contains a single file of like five lines. It feels like knitting a castle. Vue certainly has its own cruft, but it's at least somewhat simpler when it comes to how components compose.

acemarke 10y ago
The "container/presentational" component pattern is completely optional. If you want to write components that both fetch and display data, that's entirely up to you. Dan Abramov, who wrote the most widely referenced post discussing the topic ([0]), recently said that he somewhat regrets writing it because many people have assumed it's a strict rule that must be followed ([1]). That said, it _is_ a very useful pattern, and can help with conceptual management of components. I have links to a number of additional articles discussing this pattern as part of my React/Redux links list ([2]). [0] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... [1] https://twitter.com/dan_abramov/status/802569801906475008 https://twitter.com/dan_abramov/status/802569801906475008 [2] https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#component-categories https://github.com/markerikson/react-redux-links/blob/master...
- IgorPartola 10y ago
  Thanks for the perspective. I guess I ran into this very thing. React itself is actually a pretty simple library. The problem is that it's not the whole story, so you need other bits and pieces to put together a functional SPA. Ender redux, react-router, etc. And because React tries to explicitly not be so opinionated about what you should use, the way you learn about this stuff is not from the official tutorial, but from various blog posts. There are also resources like this: https://github.com/kriasoft/react-starter-kit https://github.com/kriasoft/react-starter-kit. On the surface it's great. But for my taste it's organized very poorly. You have all your reusable (NB: reusable != reused) components in one place, and all your pages in another. Each component consists of exactly 3 files that are 3 directory levels down. Pages (views? containers?) are in a separate directory structure where each page consists of 3 files that are 3 directory levels down. I guess if your SPA consists of hundreds of pages/views/containers with most components reused many times this makes sense. For my applications (low dozens of pages/views/containers) this seems like a huge overkill. And don't get me started on the redux theory of all global state all the time, which actually seems to not be ideal for things like "I just want a more complex <select>", and you have a very scattered learning curve. By contrast, Vue has a pretty sane slightly opinionated learning curve. Sure, there are a few things you need to figure out (XHR/Websockets + VueX + promises don't have a decent recipe in the docs), but overall it's much more coherent.
  - acemarke 10y ago
    Please don't mistake the opinions of various boilerplate projects for authoritative info on how to use React (or Redux). The React team makes it a point to encourage people _not_ to use boilerplates as a learning tool, as they are almost always ridiculously over-engineered and over-configured, and therefore a source of confusion for someone who is trying to learn things. You should use whatever file structure works best for you. "Folder-by-file-type" is common, as is "Folder-by-feature". My links list has a category discussing various project structures ([0]), but that's completely up to you. Redux's global state has tradeoffs. There's a lot of value in keeping your data outside the component tree (passing data between components that aren't directly related, making hot reloading easier, etc), as well as benefits to having a lot of logic be centralized (consistent handling of API responses, logging of dispatched actions). The tradeoff is that some aspects do become more complicated. However, it's also important to note that YOU ARE NOT REQUIRED TO KEEP EVERY LAST BIT OF DATA IN REDUX!!!!! People have over-interpreted the phrase "single source of truth", and game-of-telephoned that to mean "You _must_ keep _all_ data in Redux". No. NOT true. Per the relevant Redux FAQ entry ([1]): > Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it. So, if it makes sense to keep a bunch of data for a <select> in the component that's rendering it, do so. Finally, that "bits and pieces of info" aspect is exactly why I've put together my links list: to try to provide a single place that points a reasonably vetted selection of good info on React/Redux-related topics. [0] https://github.com/markerikson/react-redux-links/blob/master/project-structure.md https://github.com/markerikson/react-redux-links/blob/master... [1] http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing...
    - SamBam 10y ago
      > The React team makes it a point to encourage people _not_ to use boilerplates as a learning tool What I would love to see is one of those over-engineered React+whatever boilerplate project that shows you, in a step-by-step form, showing the evolution from a simple project to the final boilerplate they have, and why it exists like that. I have created a fairly-large project in Redux, but as I created it I know that it wasn't the "optimal" way of architecting it. So, before starting another project, I tried starting from the "react-redux-starter-kit" project, and it was immediately over my head. I have to instantly grok how they're using the router, layouts, stores (I thought Redux didn't use stores...), modules... the source even has explicit references to the way WebPack is going to lazily load stuff, so I don't even know if I could use some other build system without breaking the source. I'd love to see the same project laid out as a series of refactorings: 1. Here we have a really simple Redux project, the way a beginner might code it 2. They realize they need routes. Let's refactor the code to include the router 3. The realize it would be better putting the related-components in their own folders. Here's that refactorization. ... X. Look, your project now looks like the starter project!
android521 10y ago
Untiil there is a Vue Native. Vue.js will never be appealing to a lot of people.
- 91bananas 10y ago
  It's in the works: > "Native Rendering The collaboration with Alibaba’s Weex project has made some substantial progress. Our first major goal — making Vue 2 the actual JavaScript runtime framework on top of Weex’s native rendering engine — has been completed in the latest 0.9.4 release. In 2017 there will be revamped documentations, better onboarding experience and API improvements based on feedback from the community and large-scale production use at Alibaba." https://medium.com/the-vue-point/vue-in-2016-8df71d98bfb3#.uzzbgq7wj https://medium.com/the-vue-point/vue-in-2016-8df71d98bfb3#.u...
- IgorPartola 10y ago
  Agreed. ReactNative seems like a huge selling point.
Kiro 10y ago
I don't know how you build your Vue apps but I think you should be using the same pattern there. So it's not really an argument against React.
BurningFrog 10y ago
"It feels like knitting a castle." Google confirms this expression was coined here. Thank you!
- IgorPartola 10y ago
  I feel like I might be paraphrasing something but I can't remember where I heard it first or the original form.
  - Jach 10y ago
    It's from a Rich Hickey talk.
kozikow 10y ago
I'm loving Vue. I went from not writing javascript in 2 years (last stopping at Angular 1) to writing nice javascript app with clean codebase in a day. After a brief look at React and my experience with Angular 1, the same would take at least 2-3x longer with React or Angular. I was annoyed by Javascript community churning out a new tool every week and deprecating everything every year. I lived through learning Ember and Angular1. Now, I just picked up Vue, a few crucial components from Vue MDL and wrote everything else in plain Javascript, CSS and a little bit Jquery. And just included scripts in my html. That's it - you get two innovations of Javascript world that make the biggest difference, two way data binding and components, at the least possible cost. It saves you from all the madness of https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.c98ag0thn https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... , half of which will be likely deprecated in a year anyway. This workflow is likely more productive for 95% of sites, unless you are relaly building a complex single page web app. It will be more resilient to the passage of time.
- Kiro 10y ago
  What did you use jQuery for?

acemarke 10y ago

The "container/presentational" component pattern is completely optional. If you want to write components that both fetch and display data, that's entirely up to you. Dan Abramov, who wrote the most widely referenced post discussing the topic ([0]), recently said that he somewhat regrets writing it because many people have assumed it's a strict rule that must be followed ([1]). That said, it _is_ a very useful pattern, and can help with conceptual management of components. I have links to a number of additional articles discussing this pattern as part of my React/Redux links list ([2]). [0] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... [1] https://twitter.com/dan_abramov/status/802569801906475008 https://twitter.com/dan_abramov/status/802569801906475008 [2] https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#component-categories https://github.com/markerikson/react-redux-links/blob/master...

IgorPartola 10y ago
Thanks for the perspective. I guess I ran into this very thing. React itself is actually a pretty simple library. The problem is that it's not the whole story, so you need other bits and pieces to put together a functional SPA. Ender redux, react-router, etc. And because React tries to explicitly not be so opinionated about what you should use, the way you learn about this stuff is not from the official tutorial, but from various blog posts. There are also resources like this: https://github.com/kriasoft/react-starter-kit https://github.com/kriasoft/react-starter-kit. On the surface it's great. But for my taste it's organized very poorly. You have all your reusable (NB: reusable != reused) components in one place, and all your pages in another. Each component consists of exactly 3 files that are 3 directory levels down. Pages (views? containers?) are in a separate directory structure where each page consists of 3 files that are 3 directory levels down. I guess if your SPA consists of hundreds of pages/views/containers with most components reused many times this makes sense. For my applications (low dozens of pages/views/containers) this seems like a huge overkill. And don't get me started on the redux theory of all global state all the time, which actually seems to not be ideal for things like "I just want a more complex <select>", and you have a very scattered learning curve. By contrast, Vue has a pretty sane slightly opinionated learning curve. Sure, there are a few things you need to figure out (XHR/Websockets + VueX + promises don't have a decent recipe in the docs), but overall it's much more coherent.
- acemarke 10y ago
  Please don't mistake the opinions of various boilerplate projects for authoritative info on how to use React (or Redux). The React team makes it a point to encourage people _not_ to use boilerplates as a learning tool, as they are almost always ridiculously over-engineered and over-configured, and therefore a source of confusion for someone who is trying to learn things. You should use whatever file structure works best for you. "Folder-by-file-type" is common, as is "Folder-by-feature". My links list has a category discussing various project structures ([0]), but that's completely up to you. Redux's global state has tradeoffs. There's a lot of value in keeping your data outside the component tree (passing data between components that aren't directly related, making hot reloading easier, etc), as well as benefits to having a lot of logic be centralized (consistent handling of API responses, logging of dispatched actions). The tradeoff is that some aspects do become more complicated. However, it's also important to note that YOU ARE NOT REQUIRED TO KEEP EVERY LAST BIT OF DATA IN REDUX!!!!! People have over-interpreted the phrase "single source of truth", and game-of-telephoned that to mean "You _must_ keep _all_ data in Redux". No. NOT true. Per the relevant Redux FAQ entry ([1]): > Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it. So, if it makes sense to keep a bunch of data for a <select> in the component that's rendering it, do so. Finally, that "bits and pieces of info" aspect is exactly why I've put together my links list: to try to provide a single place that points a reasonably vetted selection of good info on React/Redux-related topics. [0] https://github.com/markerikson/react-redux-links/blob/master/project-structure.md https://github.com/markerikson/react-redux-links/blob/master... [1] http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing...
  - SamBam 10y ago
    > The React team makes it a point to encourage people _not_ to use boilerplates as a learning tool What I would love to see is one of those over-engineered React+whatever boilerplate project that shows you, in a step-by-step form, showing the evolution from a simple project to the final boilerplate they have, and why it exists like that. I have created a fairly-large project in Redux, but as I created it I know that it wasn't the "optimal" way of architecting it. So, before starting another project, I tried starting from the "react-redux-starter-kit" project, and it was immediately over my head. I have to instantly grok how they're using the router, layouts, stores (I thought Redux didn't use stores...), modules... the source even has explicit references to the way WebPack is going to lazily load stuff, so I don't even know if I could use some other build system without breaking the source. I'd love to see the same project laid out as a series of refactorings: 1. Here we have a really simple Redux project, the way a beginner might code it 2. They realize they need routes. Let's refactor the code to include the router 3. The realize it would be better putting the related-components in their own folders. Here's that refactorization. ... X. Look, your project now looks like the starter project!

android521 10y ago

Untiil there is a Vue Native. Vue.js will never be appealing to a lot of people.

91bananas 10y ago
It's in the works: > "Native Rendering The collaboration with Alibaba’s Weex project has made some substantial progress. Our first major goal — making Vue 2 the actual JavaScript runtime framework on top of Weex’s native rendering engine — has been completed in the latest 0.9.4 release. In 2017 there will be revamped documentations, better onboarding experience and API improvements based on feedback from the community and large-scale production use at Alibaba." https://medium.com/the-vue-point/vue-in-2016-8df71d98bfb3#.uzzbgq7wj https://medium.com/the-vue-point/vue-in-2016-8df71d98bfb3#.u...
IgorPartola 10y ago
Agreed. ReactNative seems like a huge selling point.

Kiro 10y ago

I don't know how you build your Vue apps but I think you should be using the same pattern there. So it's not really an argument against React.

BurningFrog 10y ago

"It feels like knitting a castle." Google confirms this expression was coined here. Thank you!

IgorPartola 10y ago
I feel like I might be paraphrasing something but I can't remember where I heard it first or the original form.
- Jach 10y ago
  It's from a Rich Hickey talk.

kozikow 10y ago

I'm loving Vue. I went from not writing javascript in 2 years (last stopping at Angular 1) to writing nice javascript app with clean codebase in a day. After a brief look at React and my experience with Angular 1, the same would take at least 2-3x longer with React or Angular. I was annoyed by Javascript community churning out a new tool every week and deprecating everything every year. I lived through learning Ember and Angular1. Now, I just picked up Vue, a few crucial components from Vue MDL and wrote everything else in plain Javascript, CSS and a little bit Jquery. And just included scripts in my html. That's it - you get two innovations of Javascript world that make the biggest difference, two way data binding and components, at the least possible cost. It saves you from all the madness of https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.c98ag0thn https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... , half of which will be likely deprecated in a year anyway. This workflow is likely more productive for 95% of sites, unless you are relaly building a complex single page web app. It will be more resilient to the passage of time.

Kiro 10y ago
What did you use jQuery for?