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.
Related
I'm working on a structure for a React application. We have ./src/Assets/Images folder, but should I put all component assets there? or I should put each component's assets to it's folder?
I mean: ./src/Components/Loading/animation.gif
or: ./src/Assets/Images/animation.gif
I'm actually interested to design a maintainable and clear structure for this app.
What do you think? which pattern is better for development and the feature...
You know, I've separated Styles but have doubt on Images??
This must be an opinion based question and it isn't something you should care that much about to be honest. It's personal preference but if you ask me, it's better to keep you assets in a same folder so your components' structure won't get messy.
I would like to say "all in one place" is good. Assets that are required to be loaded, for example images for navigation should be placed in public folder as it is much more comfortable to use. You just need to set url to point it.
For other cases, I think it is better to place it in component's folder.
I think tree structure is easy to maintain and scalable. Let's imagine that you need to update a component. In that case, you just need to update files in the same folder. If it is located somewhere else, this can lead to potential problems: for example, you need to make sure that it is not used by other files.
To sum up, I think it is good to place assets in the component's folder.
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 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.
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.
I am using backbone.js in a legacy app to rewrite separate pages into individual bits of backbone work.
I am not using any routing and it is not a total single page application.
Only certain pages are individual backbone.js applicaitons.
At the moment I have all my backbone javasript in one file for each page that uses it which is painful to work on.
Would it be wise to use something like requirejs on a page by page basis or is there something better I could do in order to split the page up in development and serve one page in production?
That depends largely on what your existing codebase looks like.
RequireJS is a great tool...if your existing code is set up to support it, or you have a small enough codebase to be able to convert it without breaking everything. However, not all legacy JS code is, especially if it's part of a larger system (I personally ran into this problem with a Backbone project I'm working on). If you can, then by all means, make use of it. The big advantage, as far as I know, with RequireJS is that it doesn't actually fetch and load the Javascript files until you need them. So you can have one RequireJS call that's in all of your pages, and only download what you need, when you need it.
There are other ways, however, to combine your Javascript code at production time, which, again, depends greatly on your setup. Many content management systems include "minify" scripts that handle it automatically for all of your Javascript files. You can also do it "by hand" with Minify, YUI Compressor, or one of the many other minification tools out there. (You can also do it "really by hand", and develop in multiple files and combine them via copy+paste, but that's really more work than is necessary.)
Regardless of how you go about doing it, I highly recommend breaking your projects into multiple files (not only into a file for different projects, but multiple files within the projects, to hold each view and models if they have significant code). It makes it infinitely easier to maintain.