How is a "component" different from a "view"?
A view is made up of many components.
Most of your components should be made up of smaller components. I'm not sure why this distinction is useful?
How to Structure React Projects
11–20 of 45 posts
Re: How to Structure React Projects
#12How is a "component" different from a "view"?
Per my understanding, a component is meant to be a re-usable unit which can be included in one or more views. A View can be thought as a single 'page' of the application, (eg: Login, Home, etc) which may be composed of several components.
Re: How to Structure React Projects
#13Earlier quoted context omitted.
A view is made up of many components.
Most of your components should be made up of smaller components. I'm not sure why this distinction is useful?
I've never done it this way, I keep calling my container components, components. In my projects I do not make a distinction and call them views. I was just stating the author's point.
Re: How to Structure React Projects
#14Earlier quoted context omitted.
A view is made up of many components.
Most of your components should be made up of smaller components. I'm not sure why this distinction is useful?
I see view (or screen) as something that maps to a route. It's true it's definitely a component.
I feel adding vocabulary like this to a system can help with understandability. That's the point I made with a "feature". It's something that could fit between views and components.
Atomic design (http://patternlab.io/) is close to this idea.
Re: How to Structure React Projects
#15How is a "component" different from a "view"?
A component is is meant to be re-used in different contexts, a view not necessarily.
Re: How to Structure React Projects
#16How is a "component" different from a "view"?
A view is made up of many components.
While the “views are many components” reply is true that’s not really the distinction. Views are React components that have state or other complexity to them. Components are React components that just consume props and return DOM that may reference those props but nothing else in your app (they won't look at state, globals, etc.)
Re: How to Structure React Projects
#17This is great! One of the most confusing things with React and Angular or in fact any other non convention-over-configuration framework is how you go about building your project. Structure is super important, and this resource looks good. I would add a demo application on Github that does handle data (something super simple will suffice), just so people can fork the project and take it from there. I know for me, when…
Agreed, structure is very important, and resources like this help codify that structure. One of the best aspects of frameworks like rails is a rock-solid project structure. New engineers so rarely have to ask questions about where some particular resource is located.
Re: How to Structure React Projects
#18I'm not in tune with the whole web thing, but nothing says overbearing framework like "structure guides" and scaffolding tools.
I'm particularly in awe because I just visited the ReactJS site to find out what all the fuzz is about and it makes the bold claim "just the UI", and "the V in MVC".
Re: How to Structure React Projects
#19I'm not in tune with the whole web thing, but nothing says overbearing framework like "structure guides" and scaffolding tools. I'm particularly in awe because I just visited the ReactJS site to find out what all the fuzz is about and it makes the bold claim "just the UI", and "the V in MVC".
This is not necessarily a React thing. When using React, or most front end frameworks, none of them care about how you structure your project. This is more about how to structure a project that starts getting really big. I've done it. Well over 100 views in a spa, with hundreds of components...your structure must evolve with the project. At some point you will probably need a dumb components and smart components separation.
Re: How to Structure React Projects
#20Just the other day I started with https://github.com/fortruce/react-fullstack-skeleton/ as a minimal skeleton for a new project of mine. Having not developed with "modern" Javascript yet, and only having used React by itself this was quite a convenient way to get started. Most other skeleton projects were too much, too huge for my taste when getting started. It has: * react-hot-loader which causes your changed to get…
That's a nice setup. Only thing that is incompatible with our react redux setup is thunk. We use redux-promise to work with async/await from babel stage 0.