The likes of NextJS or NuxtJS offer clean architectures concerning folders and files. Not to mention all the automations available, they provide a simple architecture that we have accomodated to our project:
- entry points ~ pages
- UI/UX "view-model" logic ~ components
- some "model-view" logic ~ stores
- misc related stuffs ~ plugins
Components
- it is easier for newcomers to provide a clean
"/components"
folder, each file containing its unique component - it can be heavy, but always well decomposed (eg. the Diffgram project, or simply by adhering to nested folders strategy)
- following a "folder-by-type" pattern, ie. a mix of:
- business's folders (
"/components/employee"
,"/components/authentication"
) - or applicative ones (
"/components/bootstrap"
bearing all the reused custom components for UI/UX, etc.)
- business's folders (
Pages
- discerning entry points is a nice addition, these components will bear the maximum of logic: sometimes for prefetching data for the future printed view, other times for handling a maximum of UI-async logic (eg. starting prefetching data, displaying some placeholders/spinners during the process)
- with a distinction between
pages
/layouts
/components
, it proposes a welcomed frame where atomic design principles can thrive - here are the similarities of our pages with NuxtJS:
- provide a "premount" hook used to fetch data to hydrate the page to be rendered
- provide middleware possibilities that can be registered from the "premount" hook
- provide a
"/layouts"
folder, expressily used for reused purposes (each "page" needing to subscribe to a layout)
- POC on nested pages
-
automate the hydration of the
Routes
-
automate the hydration of the
Layouts
Predictable state container businesses
- not every project needs such libraries, as Dan Abramov says, “its all about local vs. global”
- more on that, he also says that this is fundamentaly a pragmatic question
- some quick notes:
- state persistence and state container are related but quite different things, in a nutshell the former is a layer on top of the latter
- what is the truth about global state? In fact “There’s no such thing as “global state”. It’s a myth.”
- did Dan Abramov really tweeted that state containers (Redux here) become useless? Kind of, but here the contextualised response of a Redux maintainer on this subject
- clean architecture application patterns often rely on a state container (one example here)
- so with this in mind, the proposed architecture of NextJS (or NuxtJS) just offers both options
- and basically, the Store implemented in this project is not so far from what we can see with Vuex, ie:
- on application mount, generate all the store boxes from default values
- before application first render, add an entry point hook (cf.
"~/src/plugins/Core/StartUp
) - each component/hook/context can ask for a reference to the Stores (
"~/src/plugins/Hooks/useStores
): usage is basically the same as the "purescript-react"getProps
-
automate the hydration of the
RootStore
How this project is structured
├─┬─ components
│ ├──── bootstrap: structural components of Bootstrap v4
│ └──── ~
│
├─── pages: containing a component, a layout subscription, and a premount hook
│
├─── layouts: containing a component, and a premount hook
│
├─── stores: each file containing a store (ie. a record of Toestand boxes)
│
├─┬─ plugins
│ ├──── core: core application related businesses
│ ├──── hooks
│ └──── contexts
│
├─┬─ assets/sass
│ ├──── main: Gargantext main CSS file
│ ├──── bootstrap: Bootstrap v4 CSS file
│ └──── vendor: other misc CSS files
Routing operations
- provide a hook easing redirection (component render side or hook side: cf.
~/src/Plugins/Hooks/LinkHandler
) - add a native loading bar component such as NuxtJS: whenever the page is rendered and take a certain amount of time, a feedback is displayed to the user
- cancel current premount hook computation if a change of route is being made in parallel
- safely redirect on middleware or premount error (eg. if the user is not authenticated)