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.
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'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've been working on a large TS project for work and absolutely love it. When the project started we stored all of our custom-defined interfaces and types in a single types.ts file, which just exported each of them. That way, we could import only the types we needed in each module (in our case, React components). In this sense, we essentially have a global.d.ts file as defined here with the added benefit of it actually being a module because of the export syntax in types.ts.
Of course, the project has scaled and it's really time to move these definitions elsewhere. My question is how to actually build out separate .d.ts files to do this. Should I have separate .d.ts files for each component (or perhaps component group) and then reference them in a single index.d.ts? Should I just stick with what I have? Other suggestions? Really I'm just looking for advice on how other devs manage type definitions in a scalable, maintainable way. We are using TS 2.4.2 with React, Redux, redux-saga, and webpack.
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.