Open nwmcsween opened 9 years ago
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
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.)
Keeping rendering functions in separate files helps when you're doing hot reloading (as in #180). I like @jxson's structure.
Wondering what the best way to structure a mercury application?
How about: stores - serialization states - schema events - actions views - rendering