I notice that a lot of projects name their react components with uppercase class names and lowercase filenames. Why would that be different?
I believe that would not be the best practice. The filename should be the same as the React component's, and should be written in PascalCase.
For instance: Navigation.jsx exports Navigation
Further reading about naming conventions:
Stackoverflow question
Bonus: Structuring files and folders in a React project:
Yay, Hackernoon again!
Alexis Mangin's post
You probably don't need to read this if you don't use redux, but it has a good comparison between function-first and feature-first grouping techniques. Alex Moldovan's post
Edit: From nextjs official website
Next.js will serve each file in /pages under a pathname matching the
filename.
For example, /pages/about.js is served at site.com/about.
Therefore in case of Nextjs, they wanted to separate component and page files as page files are used for routing.
I think is that the same as all javascript frameworks, that should be
Presentational and Container components are kept at src/components
Group components by module/feature.
Keep generic components inside src/components/UI Keep screens simple,
with minimum structure and code.
List item Group screens accordingly to route
definition. For a route /user/list we would have a screen located at
/src/screens/User/List.jsx.
something like this Finally, our application would be structured like that
here is a valuable resource to take as reference
Related
I want to do three things in my application, but I’m not figuring out how I could do that using Next.js router.
The default URL of the application should be 'https://localhost:3000/en'
It should also be possible to have 'https://localhost:3000/es' as a valid URL
Anything different than '/es' should redirect to '/en'
(This parameter will influence on the displayed language of the application.)
Considering those three points, should I create inside pages folder a new folder called language and put my index.tsx file and all the others routes that I have?
Example here
If I do that, what are the rules that I should create on my next.config.js to match with the criteria that I listed above? If not, what could be another approach to solve this?
I want to develop a multi-page React app, where you have multiple HTML files instead of a single HTML with routes. However, so far all the solutions I found require a Node.js server.
After much struggle I eventually wrote a webpack config file to generate multiple HTML files myself, which generates multiple HTML files according to a certain file name pattern that I defined. The config file, however, is not something easy to maintain.
Then I wonder: isn't there a standard solution for that?
It is not a part of the pure React library, but quite a few frameworks that are based off React have a routing and html-generating solution for you.
Have a look at Gatsby, which is what I use for your exact scenario.
Each .js file inside src/pages will generate its own page in your Gatsby site. The path for those pages matches the file structure it’s found in.
I am using django on the backend and on the front end I am using react with create-react-app.
I have different apps on my web page that are somewhat independent from each other:
mydomainname/home
mydomainname/foo
mydomainname/bar
They are all somewhat connected but logically completely different which is why I separated them.
Is this handled with only one create-react-app and one index.html file in the build folder? And something like the browser router package for the different apps?
For example, if I look at the Facebook homepage (in case I want to build that with React) I understand that my news feed and my profile page and other people's pages are all connected and share similar components which is why it would make sense to have one index.html file.
But if I create a new public page (e.g. for a business figure), are all these components and functionalities handled in the same one index.html file? I could imagine that this will run into memory leaks and performance issues, or is this not the case? I can't seem to find anything about that neither in the create-react-app documentation nor through google.
React is not Html. In React you have only one page named index.html in folder public. The "pages" in react are named as 'Components', so you just create components and link them to each other. The first generated example component is App (App.js) component in src folder. All the transitions (transition from one component to second) will be done in index.html file.
So the question is if it is possible to split a React app into two different separate apps hosted on two different hosts, where the app A is a kind of a frame which controls the app B and C in the future. I have a problem, where I would like to make a common fundament for both apps (the A app) and then load two other as a content of it. It would be as if I had lazy loading with a bundle fetched from a different place. I was thinking about three main possibilities:
Iframe
Single SPA project from github
using ReactDOM.render method
I am not sure if it is possible at all, beacuse there still may be a problem with React Router - does the inside app have access to manipulate the browser routing?
It is quite possible to split your react Application into multiple smaller react applications.
Suppose you have a react application such as an e-commerce platform . You can choose to write the cart Page using a separate react-App and the products page using another separate react app and integrate them together using Module Federation Plugin webpack/lib/container/ModuleFederationPlugin.
A good reason to do something like that would be to develop different parts of your application in isolation ..and they can be taken care by different teams altogether.
There is a udemy course that teaches you exactly that. Very much recommended. You can make react dependency as singleton to avoid several installs of react.
All 3 of these options you've stated are valid and can be used to share components but there are few disadvantages to each one, for example- iFrames makes it hard to create responsiveness, ReactDOM splits your app so that the different parts won't have the same global scope...
Module-Federation is the best and most efficient way to share remote components that i know of, here is a github link to a basic project.
The MF plugin makes use of webpack's abilities, which means that the shared components are being consumed as runtime objects of the app's scope, rather then as a promise of an iframe.
NOTE: Debugging and updating a Module Federation project is a much deeper task then debugging a create-react-app application, you'll need to share dependencies correctly and remember to update desired changes at all the right places all the time.
This is not possible. Each react app can only have a single package.json in the hierarchy. if you nest it, the app will fail and say you have several installs of react. what you should do is think more react minded and objecty. You can have a folder for common components to share inside src/. You can also have src/A which is one "app". src/B which is another.
What you described in your question is exactly what you should do, just dont think of it as a react app separation, rather a seperation of component and app inside the src folder. App A can be comprised of components from /components as well as App B.
I've been messing around with Angular and i wanted to split all the files up according to their role in my app.
I want a folder for each "page" like /home or /products and take care of everything within their respective folder(It sounded like a great idea).
However, now i'm not sure how to approach loading these files in or even where to do it.
This is my current file structure:
Due to certain limitations im not able to use other helpful tools, this needs to happen in the code directly.
What would be the best way to approach this?
1st part of your question:
There's no default way to organise your angular app.
However, there are some guidelines. I keep thanking myself for reading the Angular 1 app-structuring-guidelines by John Pappa which enlightened me on the same question you are asking.
At the moment, I have organised all my apps in a folder-by-functionality apprach rather than a folder-by-type one (i.e. all controllers in a controllers folder, all services in a services folder,etc).
2nd part of your question:
Just use Gulp or Grunt and then import the single file in your index
The Web is getting more and more component oriented, now all the most famous frontend frameworks adopt a reusable component policy (React and Angular 2 relies heavily on it)
If you want your angular app to be as modular as possible, you have to put everything regarding a component in a separate folder (html templates,css styles and js logic),and split the shared logic between services and assets
In Your case an example of project structure could be:
app/
assets/
//put here images,fonts and shared styles
services/
apiService.js
utilsService.js
etc etc ...
components
home/
home.js
home.css
home.html
products/
products.js
products.css
products.html
etc etc/...
index.js
index.html