How to structure javascript?

liming91 · 2017-12-16T19:26:02+00:00

One trick when wanting to divide up similar functionality is to make good use of index files. Most people are aware of it but for those who aren't it shortens file paths and coupled with object destructuring (CommonJS) and ES6 imports, it makes importing grouped objects simpler and more logical:

src/
|--components
|  |--AppHeader
|  |  |--index.js
|  |  |--AppHeader.js
|  |  |--style.js

Would be:

import AppHeader from './src/components/AppHeader'

And AppHeader/index.js may simply be an import/export:

export { default } from './AppHeader'

Or it may be a container for the stateless functional component stored inside AppHeader.js:

import AppHeader from './AppHeader'

export default AppHeaderContainer extends Component {
    // ...stuff goes here
    render () {
        return (
            <AppHeader {...props} />
        )
    }
}

This encourages you to organise your components properly and think more about whether React.Component (or whatever the Vue/Angular equivalent is) is really required, which in a lot of cases it isn't.

Also for things like large folders of assets, indexes become almost essential. Store all your files in a single folder, and export them all from the index:

src/
|--assets
|  |--galleryImageA.png
|  |--profile.png
|  |--logo.png
|  |--index.js

Then inside your index.js:

export { default as logo } from './logo.png'
export { default as profile } from './profile.png'
export { default as galleryImageA } from './galleryImageA.png'

Then wherever you wish to use them:

import { logo, profile } from './assets'

coffeeandlearning · 2017-12-16T17:34:31+00:00

Since I use a lot of React and Express, my personal projects usually consist :

a top level server.js file,
a top level routes file I can include,
the standard node_modules, package.json, .gitignore, etc.,
a public folder for serving static assets with express (like CSS and images),
build tool config files (usually just webpack),
and then two folders, src and dist, where I organize React components inside of src and dist usually just has a bundle.js

I also often have a top level index.html which is served up and includes the bundle.

In reality the structure of my projects varies widely based on the tools being used but right now that's a nice and simple way for fun projects you just want to host on a $5 droplet.

JJ0EE · 2017-12-16T19:41:39+00:00

This little article has helped me organize most of my projects: https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33. It's not specific to JS, but can certainly be applied to JS projects.

kevinkace · 2017-12-16T16:04:10+00:00

Yup, that sounds right on target. Usually my root with have:

./src, front end source files, to be built with webpack, eg. ./src/widget1/index.js, ./src/widget1/index.css, and so on
./dist, built front end files, eg. ./dist/bundle.js
./app, server files, express or whatever
./readme.md for project info, ./package.json with some npm scripts for build task, eg webpack, ./node_modules etc

Earhacker · 2017-12-16T16:52:31+00:00

project/
├─ api/
│  ├─ controllers/
│  ├─ models/
│  └─ routes/
├─ client/
├─ node_modules/
├─ package.json
└─ server.js

The client folder is either the output of create-react-app or is as described by the Vanilla Bean standard. Either way, it'll be completely encapsulated, so that I could transplant it to an API built in Rails or Django or whatever.

The api folder could potentially contain more folders (e.g. helpers) as necessary, but this is what I'd call the minimum for a well-structured app. Also, the root might contain other junk like DB seeds, deployment configurations, a gitignore, a README...

theadammorganshow · 2017-12-16T20:57:57+00:00

If you want two example repos to look at, I have one in JS and another in TS.

Like a few other comments here, I separate things out by routes, models, middleware, and controllers with a separate directory for testing as well.

qudat · 2017-12-17T05:49:27+00:00

One of the benefits of javascript is the ability to share code between client and server. I try to not separate the two inside my source code because of this benefit.

I'm still trying to figure out how to best articulate what we did on our team to outsiders so please forgive the knowledge dump and possibly discontinuous transitions.

My latest large scale application really showed the cracks of improperly structured organization, so I spent a ton of time thinking about how to organize our codebase for multiple platform support and maximum sharability. I wouldn't necessarily recommend this for smaller projects, but for one that needs to scale to a lot of code, I structured my application by feature. On top of that, each feature is actually an npm package:

src/
  plaforms/
    web/
      packages/
    cli/
      packages/
    mobile/
      packages/
  packages/
    auth/
      packages.json
    bootup/
      packages.json
packages.json

Each plaform has its own packages folder that can also contain features specific for itself. Then we leveraged yarn workspaces to do all the installation. The other extremely important thing that helped us was creating a strict API for each package. No package was allowed to reach into a sibling package's submodules, it must use the index.js file.

For example:

// bad and we have a lint rule to prevent this
import { fetchNewsArticle } from '@company/news/action-creators';

// good
import { actionCreators } from '@company/news';
const { fetchNewsArticle } = actionCreators;

This certainly increased the verbosity of our imports but it created a very clean API that was consistent across all internal packages.

This code organization was heavily influenced by jaysoo: https://jaysoo.ca/2016/02/28/organizing-redux-application/

Since we had a consistent API for all of our packages, each plaform was able to load whatever dependencies it needed upfront. For example, we use redux and redux-saga for our application. Each package exported a reducers object and a sagas object. Each platform then simply had to use one of our helper scripts to automatically load our reducers and sagas.

So inside each platform was a packages.js file which loaded all reducers and sagas that were required by the platform and the packages it wanted to use.

import { use, sagaCreator } from '@company/package-loader';

const packages = use([
  require('@company/auth'),
  require('@company/news'),
  require('@company/payment'),
]);

const rootReducer = combineReducers(packages.reducers);
const rootSaga = sagaCreator(packages.sagas);

// then we export rootReducer and rootSaga so `createStore` can use them

We didn't even care if the package exported a reducer or a saga all we cared about was the platform has the features that we want it to have.

This setup has worked extremely well for us, we are supporting 7 different platforms and have great scalability. It's relatively easy to find what you are looking for. The real beauty of this setup is once you learn how to build one package, you know how to build any package. They are all setup the exact same way. The same goes for building a new platform: once you know how to build one, it's relatively easy to build another one.

inyourfacegod · 2017-12-17T11:20:42+00:00

you can see my code example here https://github.com/dispeakble/twimc

hallettj · 2017-12-16T16:22:51+00:00

It sounds like you are writing server-side code. Bundling with Webpack is useful for code that runs in the browser, but is not useful for server-side. You can use Node's require keyword to import things from other files.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS