Can we keep containers-folder outside of the components-folder ?.
And common-folder & helpers-folder inside component-folder ?
How can we arrange the below folders in components-folder ?
containers
pageContainers
common
utils
helpers
To my opinion the "modular" approach is a pretty good for react app. The purpose is to "scope" your files.
For example :
/src
/Components
/Button
index.js
style.css
/Containers
/Dashboard
/Components
...somes components used only in dashboard
index.js
style.css
/UserProfile
/Components
...somes components used only in UserProfile
/Service
fetcher.js
reducer.js
index.js
style.css
/Services
reducer.js
/auth
...
App.js
As you can see we have a "Container" folder Each "module" has his own style, component, services, utils etc...
The benefits of "scoping" your application are:
More easly maintenable
The structure is more clear for the user, you don't have ton search your "Button component" in the only Component folder were you store 100 other components
Evolutive. For exemple you have the "Auth module" wich allow the user to authenticate with your site. If you scope well your component it will be more easy to add some new ffeature for this service/component.
Of Course the general tree of folder will be bigger. You can adapt the structure with your needs but don't forget to think "scope".
This is probably not the "best way". but it has some very good advantages
if you want to go futher i recomand you the excellent article :https://medium.com/#alexmngn/why-react-developers-should-modularize-their-applications-d26d381854c1
and
https://medium.com/#alexmngn/how-to-better-organize-your-react-applications-2fd3ea1920f1
You can use fractal file structure, a comprehensive hackernoon post summarizes it all here.
It makes you reason about the location of files and folders, easier management of components, and paves way for infinite scaling.
Related
I am implementing a component library (an npm module and we'll call it awesome-components) which consists of buttons, inputs, dropdowns etc. where an end user can install it in thier react app and use these components. My confusion is what is the best way to package this library for the end user? I have two approaches in mind,
Using an index.js file to export all the components to be imported as named imports. The folder structure is as follows,
src
|-components
|-Button
|-index.jsx
|-Input
|-index.jsx
|-index.js
index.js will be implemented as follows,
import Button from "./Button";
import Input from "./Input";
export { Button, Input };
The package json's main will point to the index.js in the components root. The npm pack will bundle all the compoenents to one file and will be npm packed and npm publisheded and will look somewhat like this,
dist
|-index.js
|-index.js.map
|-package.json
The end user can import these components in thier app as follows,
import { Button, Input } from "awesome-components";
By not having an index.js in components as follows,
src
|-components
|-Button
|-index.jsx
|-Input
|-index.jsx
And bundling the components seperately and ship to the end user preserving the folder structure which will somehwat look like this,
dist
|-components
|-Button
|-index.js
|-index.js.map
|-Input
|-index.js
|-index.js.map
The end user can use these componenets using absolute path as follows,
import Button from "awesome-library/Button";
import Input from "awesoem-library/Input";
My concern is, which method will benifit the end user ? The number of components can even grow upto 20. What would be the best method to use interms of scalability and performance?
Thanks alot :)
Your first approach is preferable, for four primary reasons.
In your second approach, the paths may change at some point, which would result in a breaking change for all your users.
Submodules from your second approach are usually considered private APIs that external consumers of this package should not rely upon.
Everyone else does it the way you outline it in your first approach.
Several linters, like TSLint, complain when you use submodule imports from external packages.
I can put .css inside pages directory in a Next.js application and import it from my pages with import "./my-css.css".
Still, is it a good practice? Will it cause routing problems, or is it simply ignored by router?
In the docs it states "Every .js file becomes a route that gets automatically processed and rendered." It also looks possible to change what extensions are used: https://github.com/zeit/next.js#configuring-extensions-looked-for-when-resolving-pages-in-pages
So I don't think it will cause routing problems to have a .css file there, but I also don't think it's a good practice to put them there just because I would not expect to anything but pages in the pages folder in a nextjs app.
I have a simple project working nicely using JSX / React / Gatsby.
I have a pre-existing page (think landing page) in HTML in another project, quite complex, nicely styled using Bootstrap 4, let's call it LandingPage.html and an associated LandingPage.css.
I would like to add the landing page to my Gatsby site. So that for example when navigating to localhost:3000/LandingPage.html the landing page gets shown, properly styled etc.
I am not clear whether I have to fully convert my pre-existing HTML into a react component / JSX?
Or whether I can just serve the LandingPage.html (and associated styling files) by placing it somewhere sensible in my Gatsby project structure?
Or whether I have to create a react "wrapper" that at "run time" reads in the content of LandingPage.html and LandingPage.css?
Note: I've tried just putting the LandingPage.html and LandingPage.css into the /public folder and actually that does work! So maybe I've answered my own question. But is the the right way to do it?
As of Gatsby v2 (don't know about previous versions), it is maybe more consistent to add the file to the /static folder.
According to the docs, the /public folder is meant to be generated automatically when building the site and should be added to .gitignore.
Files added to the /static folder will be copied to /public when building the site so it should have the same effect. More info here.
Up until now I have been building my application using the following structure.
/src
/components
/shared
/messagebox
/alertbox
/Home
/About
So as you can see I have shared components which are components being used on other components / pages. and I have the concept of Home, About which are also components (which translate to viewable pages) as everything in Angular is now supposed to be a component - right?
Does anyone have a better implementation of the structure of a NG 1.5 app?
I now need to create some filters and as far as I am aware I cannot hang these off of a component, so where is the based place for putting this type of file?
Also other things that come to mind are constants, services etc.
There is no recommendation on Angular docs site as far as I can see.
The one which i used to follow for my project is :
project
/www
/assets
/components // directives
/accordion
/accordion.html
/accordion-directive.js
/accordion-controller.js
/accordion-controller-test.js
/core // shared services
/route
/router-service.js
/sections // pages we build by adding components
/registration-page
/registration.html
/registration-controller.js
/registration-controller-test.js
app.js
index.html
index-controller.js
app-configuration.json // for keeping constants
this might help you.Please check.
What is the best angular file structure for me? My project is going to be a SPA with a video feed on the main page, and pages to view specific posts. I want my users to be able to login, vote on the content and an admin section to add content.
You can see my file structure here - https://github.com/bliitzkrieg/TrailerFeed or below
/app
/assets
/css
main.css
main.min.css
/sass
main.scss
_variables.scss
/components
_header.scss
/components
/dashboard
/feed
_feed.html
feed.js
feedController.js
/header
_header.html
header.js
headerController.js
headerDirective.js
/spec
app.spec.js
app.js
index.html
routes.js
Your file structure looks fine. You have your files organized by component rather than type. I would suggest removing the underscore prefix from your templates as this is redundant. Every template in angular is a partial so they don't need to be indicated as such.
You may want to keep your unit tests in the components directory as well. headerDirective.spec.js can live with in your header component folder.
Controllers are classes and instantiated as individual instances (as apposed to services which are classes that are injected as a singleton). So controllers should be named in PascalCase rather than camelCase.
It would seem that your component SCSS should live with the rest of its component files as well. But there are very valid reasons not to do this.