As we all know, having proper file structure and naming convention is really important in building Application. I am building a medium level application in react. I need to set up a proper file structure for that which allows us to move around our code with the least amount of effort. As a beginner this is a tough situation, so I have few questions about file structure and naming components. Can anyone give a clarification about these questions?
Which is the right way to structuring components and static pages and their CSS?
How to name components for better re usability?
Where do I can keep my application level states?
Where do I can use state-full components and stateless components?
Using redux for state management is mandatory?
Is Context API enough for application level state?
Please share the right information against this.
Thanks!
Redux is not required and, depending on your application's complexity, Context API should work just fine
I typically use a container component pattern where I have a Container that fetches my data and it delegates it to child components, which are usually stateless. More about that particular pattern here.
Unlike the example I linked above, I usually abstract away any fetching logic to service files that exist in a services directory.
Which is the right way to structuring components and static pages and their CSS? There is no "one right way" to structure your application. Couple of patterns I've noticed people using are;
You can use even your own structure but the important thing to keep in mind is that it should be consistent across your application.
How to name components for better re usability? I have noticed two variants;
Where do I can keep my application level states? There are several depending upon the use-case, sorted by ascending code complexity : Context API, Redux/Mobx, localStorage/sessionStorage, IndexedDB, WebSQL.
Where do I use state-full components and stateless components? If a component owns a responsibility(more than rendering the content) that involves remembering the data and reuse it for every render then it requires a "state" to be maintained in that component whereas if a component involves only rendering the content and probably some actions around it but doesn't store the data then that makes it a stateless component.
To help you decide, here's a tip, while creating a component try to figure if the component can be broken down into further small components. Do this repeatedly until you cannot break it down further. After this, try to depend upon the state of the parent as the props for the child component instead of directly introducing a state. If the child component itself owns a responsibility only then introduce a state. In the process of props passing, make sure you wouldn't end up with a messy code.
There are couple of patterns in React for better reusability and readability with the use of Stateful and Stateless components. One of the answers have mentioned it.
Using redux for state management is mandatory? Is Context API enough for application level state? Depends upon how big your state is to manage. If its big and is being interacted by several components then probably yes otherwise I'd never recommend Redux as it creates one more headache of managing the state, instead use Context API. Infact, in React 16.6, Context API can be used outside the JSX too.
Cheers!
Which is the right way to structuring components and static pages and their CSS?
Static pages are always stateless components (functional or PureComponent).
Any custom CSS that isn't a part of the site's overarching CSS system is kept in the component itself (with CSS in JS), inline styles (since it's static anyway and often cached), or in a separate CSS file. Depending on the project's CSS setup, I'd have a
assets/css/static/that contains each component's modular CSS.How to name components for better re-usability?
Doesn't really matter.
The component ecosystem is so large, that I often get multiple
<TextBox />imports in a single file, which thanks to ES6 are renamed (import { TextBox as MUITextBox } from 'material-ui').Where do I can keep my application level states?
Context API for simple state, like "Is the user logged in?". I reach for Redux/RxJS when the Context API is limiting, like when you need state management for SSR or complex and/or asynchronous component interactions.
Where do I can use state-full components and stateless components?
Stateful when you need, stateless when you don't. It's that simple.
It's better practice to just start stateless and add state when you start reaching for it. Eventually you'll find you can plan for these things when architecting future apps.
Using redux for state management is mandatory?
Nope. You can use your own custom store (a store.js file that gets imported across the app), any other library, pass props around, use the Context API, whatever solutions works for you and the complexity of your state.
Is Context API enough for application level state?
Usually yes, but it can depend.
When should you use Redux?:
Persisting complex state across the app
Having a complex "machine" where me turning one part effects others. Context API and prop drilling work fine, until you have 50 things to manage in your state - or the components don't align in the tree as children.
Persisting state across the server side
Local storage works great for client side, but doesn't work server side. Context API works fine for simple cases like only tracking user authentication in an app, or more localized state. So you end up using Redux and serializing the Redux object for the server side to access as well.
Easier side effects
You could use multiple context APIs to keep track of things like user auth and app-wide alerts. Or you could just dispatch one action with Redux, and dispatch two (or more events) in one, in the same function.