I'm building a website with a bunch of individual components, which I stored in a components folder in my folder architecture, and when I'm setting the routes, I constantly need to type out the whole file path. For example
let mathModules = "./components/MathModules/Programs/";
import MultiplesOf2 from mathModules+"Multiplicity101/MultiplesOf2";
For each module and future modules I constantly have to add ./components/MathModules/Programs/ where the only difference is the latter 2 substrings. The above code obviously doesn't work, but is there a way to achieve a similar effect without importing a "Routing" file that lives closer to the target path.
Related
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.
My team work on a multi page website and so far we used JS and some angularjs.
We thought to give a try to Reactjs so we added one page written in jsx and we also used webpack for the bundling (compiled by babel).
Now that we have that one page we want to expand our work with Reactjs. The first thing we have in mind is to split that (rather long) file. What does it actually means? We defined some components in it and for the first step we want to take each one of them to an individual file. My question is regarding to Webpack's entry section. I couldn't find any better approach than to add each and every file written in jsx explicitly to the entry section. It is even described in Wepback documentation: https://webpack.js.org/concepts/entry-points/#multi-page-application
Is it really the only way to do that?
In a few weeks I expect us to have at least 50 files containing pages, components and other stuff. Does a webpack file in a big project contains all the files explicitly?
Thanks.
You don't need to add every jsx file to the entry section. You only need to add your entry point.
For the component you are building, you probably have the main component (the very top, e.g., App.js) importing or requiring other (sub)components. You only need to add the top-level or main component to the entry section.
The main job that webpack does is traverse down the module graph (each import or require) and roll everything up into a bundle based on the top-level component (usually the whole app).
use imports and exports in your js files and have 1 main file that webpack looks at
I'm working on a React Native project where we will need to build two different flavours of the app, which mostly the same but vary in a few small features. I wanted to see if there was a way to do this through babel somehow, by having different files named similarly for each build and triggering differetn builds by setting and environment variable. This would be similar to the way that React Native does for having custom js files for iOS and Android like this:
my-component.android.js
my-component.ios.js
so my different build flavours would look like this:
my-component.flavourA.js
my-component.flavourB.js
or even
my-component.flavourA.android.js
my-component.flavourB.android.js
my-component.flavourA.ios.js
my-component.flavourB.ios.js
I am trying to find a way of using babel to change the require() function (and import statements) such that the correct files are resolved from a simple require call of:
require('./my-component');
depending on which FLAVOUR environment variable is set. Or:
import * from './my-component';
I have looked at trying to use a combination of babel-plugin-module-resolver, babel-plugin-replace-require and babel-preprocessor but I'm not able to work out if this even possible without writing my own babel plugin.
Is there an easier way of achieving this that I am missing?
Background: My company's web-app is in fact several completely separated apps that have minimal effect on one another. That's why it doesn't make any sense to keep them under a single project - so I'm using separate projects. However, since I started migrating and writing new apps in ReactJS (using Webpack for bundling) I find many opportunities for reuse, in order to avoid code duplication and to avoid downloading common resources again after another app already fetched them:
I'm using specific versions of 3rd party npm modules - so no reason to bundle them over and over again - and no reason to upload them to the server more than once (for all the projects).
How do you share package.json fixed versions across projects?
Do you bundle all/groups of npm modules together or each separately? I want to get everything from the server for cases of on-premise deployment.
What measures to you take to make sure you don't forget to re-bundle the node modules in case you decided to update one of them?
Similar question goes for font files (keeping the font on the server and another font for icons)
common style sheets
common JS code - like utils & common
common web.config configurations
common images (currently some of them are inline in different bundles)
and last - common components - how do you share them? Do you use a separate project and publish to npm? symlink?
Or maybe, after all, I should go with a monorepo? And how?
You could create a separate project, my_modules, which is just a manifest of the shared, common packages. You'd have a package.json with all the common modules, and a single index.js which does something like:
import React, { Component, PropTypes } from 'react';
import moment from 'moment';
export { React, Component, PropTypes, moment };
Then, you'd publish this new my_modules project to github, and install that in your other projects.
import { React, Component, PropTypes } from 'my-modules';
Every time you change a package, you'd increment the version, and then update that version in your projects (which is still a bit of a pain, but you could use something like greenkeeper.io to ensure they don't get stale).
Similarly, you can do the same thing for just about everything else you've mentioned, although you don't want to go overboard with this; you should only share standard assets that doesn't change very often, and keep project-specific assets in their own repo.
EDIT: wanted to add, for React components, this is actually a really good practice, because it forces you to write generalized, independent components. You can use something like React Storybook to create these components in isolation. You can publish one master package with all the packages, individual components as packages, or somewhere in between (eg. all Form components in one package). Either way, though, they can still share a repo for convenience.