Skip to content
This repository has been archived by the owner on Jun 16, 2020. It is now read-only.

Ideal directory structure? #163

Open
nwmcsween opened this issue Apr 27, 2015 · 3 comments
Open

Ideal directory structure? #163

nwmcsween opened this issue Apr 27, 2015 · 3 comments

Comments

@nwmcsween
Copy link

Wondering what the best way to structure a mercury application?

How about:
stores - serialization
states - schema
events - actions
views - rendering

@jxson
Copy link

jxson commented Apr 28, 2015

I tend to create individual components that have a function which returns state and a function for rendering (SEE https://github.com/Raynos/mercury/tree/master/examples/login-form). I have been structuring code similar to this:

components/
  header/
    index.js
    render.js
  footer/
    index.js
    render.js
  etc.
event-handlers/
  special-value-event.js
widgets/
  custom-widget.js
index.js

@mattferrin
Copy link
Contributor

I have a strong personalized opinion here, so I thought I would give my two cents.

index/
   layout/
      body/
         column-body/
            left-column.js
            right-column.js
         row-body/
            top-row.js
            bottom-row.js
         body-reusable-only-thing.js
         sub-header.js
         column-body.js
         row-body.js
         sub-footer.js
      header.js
      body.js
      footer.js
   layout.js
index.js
reusable-everywhere-majig.js
reusable-anywhere-thingy.js

I was working on a ReactJS project recently and was using react-router. I found that using the same nesting principle for my directory structure resulted in universally understandable structure. I haven't done so in Mercury yet, but imagine no difference in the application of the principle

@jxson How to I do that markdown thing? (I worked hard and found an example. Thanks for the inspiration.)

@crabmusket
Copy link
Contributor

Keeping rendering functions in separate files helps when you're doing hot reloading (as in #180). I like @jxson's structure.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants