I really like the separation between Components (have no idea about infrastructure, get all their data from props) and Containers (make all infrastructure stuff and pass props to Components) but I've encountered a situation where it feels quite problematic.
I have two logically separate pieces of code in my container. So it feels natural to split my container into two but I'm not sure how to manage it. What should I do with those subcontainers? Possible ways to go:
Put them in components folder under the folder of main component (that represent a page). But putting containers (subcontainers but anyway) into components folder feels wrong
Put them into Containers folder in folder by Page name (page container will just render these two subcontainers). Seems like a reasonable way to go but I've never encountered this kind of implementation.
I will highly recommend you to check react-boilerplate. The way that they structure the files are very good.
Container components:
May contain both presentational and container components** inside but usually don’t have any DOM markup of their own except for some wrapping divs, and never have any styles.
Please see this article by Dan Abramov on what
presentational and container components should contain. He explains his reasoning for this point at the bottom of the article.
Related
I am looking at a react and redux codebase that I can't unfortunately share here. The file structure has many levels of directories that follow the pattern of route directories containing component directories and the pattern repeats itself with a path. That is to say, a typical path is app/routes/charts/routes/bar/components/bar.js. In that case the components/bar.js sits next to an index.js file which is often the case (but not always). As the app has a lot of elements the directory structure is very busy. It seems that it all supports some sort of modularity, but it is a bit difficult to navigate. The fact that components sit in a route directory that recursively contains a similar path one or more times is a bit hard to understand. I'm also a bit confused about the purpose of all the nested routes directories. What I want to know is if this follows an idiomatic approach or strategy that I can look up and understand?
Unfortunately, the only person who can answer that is the person who structured the files.
Whether or not it makes any sense depends on the actual project and personal preference, but my guess would be there is a charts route in the app, with has its own child routes, one of which is bar, which may need not just components, but containers, styles, types, tests, etc., so it has its own components folder.
Ultimately, there's no right or wrong way (within reason) to build your directory structure. Provided it makes some modicum of sense and works for you/your colleagues, it's perfectly valid.
Maybe having a second routes folder is redundant, and simply having child folders with the route names would be simpler, but it's not a particularly unusual way to arrange things.
I'm getting started with React and I'm having a hard time wrapping my head around the actual "flow" of a project.
I've googled and searched around on this site regarding the structure or architecture of a React app, but most of them address file structure and often end with some variant of "There's no one right way to structure the files".
But I'm looking for something more high level than that. I'm just trying to grasp how all the pieces React provides fit together. I can't even begin worrying about how I organize my files if I don't even know entirely how each file relates to one another.
As an example of what I mean - when working with an MVC app, you have three "high level" components: model, view, and controller. Their purposes and relationships to each other are distinct. A view handles the display, a model handles the data, a controller handles the connection between them. You can find easy reference diagrams to keep track of this organization.
Of course React isn't it's own paradigm, and I know it's entirely focused on front-end, but I'm curious if there's a similar way of describing the pieces of a typical React app. How containers, components, reducers, actions, etc. all work together to make an end result.
I would agree with Marko Grešak's comment. You learn as you do and understand the code.
But, if you fill lost (which I was also), I can tell you about some architectures I saw :
A teacher of mine split the logic and the view. In one folder, you find your components, in one folder, classic JS classes that contains all the functions that handle the logic behind what the components print. Each component imported its own css file, with only the styles for this one component. We used this with MobX..
At work, we have a js folder, containing a components folder, for components that are at the 'end of the line', a containers folder, for components that have other components in them, a store folder for everything Redux, an asset folder for images and such, and a utility folder for other functions we might want to call. At the same level as the js folder, we have a sass folder. This is in no way a 'correct' or 'recommanded' way of doing things.
In general, you'll find a lot of tutorials and other things referring to dumb and smart components - splitting between the ones that just receive props and print them, and the ones accessing data and manipulating it. It's a bit like our container/component system in the end.
In the end, you're free to do how you want. Just try to keep a certain logic in how you split things so that it makes sense overall, but there is no set rules.
I wonder what is the naming convention for directories and components in react. I have the main components directory and type of components (presentational, containers, hoc, views) under it.
I also have higher order component named DifferentReportsComparison. He lives in "components/hoc/differentreportscomparison/DifferentReportsComparison.js" path, but I think that the name of directory he is a child of can be confusing because of it long name.
I would like to know how you organize your components, especially these with long names.
First off, there is no best way to organize your components. In fact, unless you're working in a team of people, the best way to organize your components is what makes sense to you.
If you look at how NextJS works, they have broken up most likely what you refer to as 'views' into a folder called pages.
But if you're worried about the long name of a component, you could either (a). figure out a shorter name. Or sometimes people will name the component file in the folder index.js. So in the case of differentreportcomparison, it would go components/hocs/DifferentReportsComparison/index.js.
When you go to import that file you can import it by just doing
import DifferentReportsComparison from 'components/hocs/DifferentReportsComparison'
But as I said there is no perfect way to organize your components, and chances are as your projects grows, you will possibly change the structure a couple times.
It is worth taking a look at popular react projects and their take on it. E.g.
Material UI and Antd. There is no absolute standard. Just try to stick to one schema.
Not sure if it's the right website to ask this question but I I'll give it a go.
When building a web app with React and Redux, how should one use the connect() function? Is the goal to only have one container connected to the store at the top that passes the props to it's children or to have multiple containers connected to the store that passes down props to their children?
I've built a small web app that only has one container that is connected to the store and therefore it passes all its props down.
I was wondering what solution was best and if it's the multiple containers connected one, how does one build his app's architecture that way?
Thank you.
Quoting the Redux FAQ at http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-components :
Early Redux documentation advised that you should only have a few connected components near the top of your component tree. However, time and experience has shown that that generally requires a few components to know too much about the data requirements of all their descendants, and forces them to pass down a confusing number of props.
The current suggested best practice is to categorize your components as “presentational” or “container” components, and extract a connected container component wherever it makes sense:
Emphasizing “one container component at the top” in Redux examples was a mistake. Don't take this as a maxim. Try to keep your presentation components separate. Create container components by connecting them when it's convenient. Whenever you feel like you're duplicating code in parent components to provide data for same kinds of children, time to extract a container. Generally as soon as you feel a parent knows too much about “personal” data or actions of its children, time to extract a container.
In fact, benchmarks have shown that more connected components generally leads to better performance than fewer connected components.
In general, try to find a balance between understandable data flow and areas of responsibility with your components.
What are the disadvantages of using one big React component?
I have a deep experience using webpack, browserify, AngularJS, ES6, NPM and other similar web framework. I am new to React.
I want to create a single page app in React. I don't want or need testing. I don't need team friends to work on. I only need to make the product development as fast as possible. Make thing works. You can call it MVP. You can call it type lessm, or smart developement. If things work good in the future I can consider refactoring the project. I am the only developer who works on. I don't worry about perfromance issue (if it is just few ms)
The question is: All the articles said to make as much as possible many and small React components. In separate files. You can see the React-Starter-Kit. It is huge.
You can see that every component is a separate file.There is huge webpack.config.js file. Every component import many other things. If I also want Redux, I need to import the store, and make connect on every component.
I want to take different approach. I want to use React & Redux. But using only one component. Every inner element can Dispatch or execute events.
Is there is any problems in the future that I don't think about?
HTML:
<html><head><body></body></html>
JavaScript:
App=React.createClass(function(){
getInitialState:function(){
return {
openMore:'block'
}
},
openMore:function(){
this.setState({openMore:'visible'})
},
render:function(){
return (
<div>
I want to put all the HTML of the app
<span>
In one component that do everything.
<button onClick={this.openMore}>More Info</button>
<span> This way I beleive I will need to type less for development</span>
<b style={{display:this.getState().openMore}}>What are the disadvance of this?</b>
</span>
</div>
)
}
})
ReactDOM.render(App,document.getElementsByTagName('body')[0])
Well disadvantages are many. I will try listing them from what I have faced and observed:-
React was built on the concept to break page into components, so yeah the more you break the page into small components the more it is easier to use.
Its generally easy to track the code.
Its scalable
One component does not break other components.
Re-rendering is there only for specified components if they are isolated. If you have everything in a single component, the rendering would make your entire component load again, reducing efficiency.
Harder to test
Difficult to use with redux while passing actions and then connecting to store.
Your component should do only one job.
Cannot break the components into presentational and container components thus not utilising redux to full potential.
Not being able to use code spilt feature of webpack which increase speed of page due to partial code loading.
These are few things I personally faced. Next,coming to webpack configuration. I hardly have configured webpack file more than 100 lines and trust me those 100 lines make your life really easier. In fact basic configuration is just 10-15 lines which can generate your bundle.
Now,coming to problems in future, yes following would be problems:-
Difficult to scale up.
Difficult to test
Not utilising libraries to their potential
Difficult to manage component due to monolith behavior.
Hope it helps!!!
Having a single large file is fine. React was built on the maxims "No abstraction is better than the wrong abstraction" and having an API with a low surface area.
If you're not sure what problems your application is solving, then wait until you feel the pain of not having an abstractions before you create one.
If your application is likely to be in flux as its feature set isn't nailed down, then don't give yourself busy work by moving things around in different files.
If you don't have a website that is designed with reusable components that are intuitively separable, than don't separate it out into different components.
It is fine to use React just as a means of having a declarative syntax for what your html should look like in different states.
Having large components is bad due that you cannot simplify your code. Splitting your modules into smaller ones, will make it easier for you to maintain the code at a longer term, as well as finding out an error faster. Stack Trace is easier as well as it is more composeable, when having an implicit component.
FWIW, you can do a lot more separating your component into smaller ones, such as filtered props and an own state. The bad thing though, is that you can loose track of how the application is built up when you are looking at the build others have made.