Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in
H
Hello Gargan
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • arturo
  • Hello Gargan
  • Wiki
  • 1—Application structure

1—Application structure

Last edited by arturo Jul 16, 2021
Page history

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:

  1. entry points ~ pages
  2. UI/UX "view-model" logic ~ components
  3. some "model-view" logic ~ stores
  4. 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.)

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:
    1. on application mount, generate all the store boxes from default values
    2. before application first render, add an entry point hook (cf. "~/src/plugins/Core/StartUp)
    3. 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)

2.1 — Component structure »
Clone repository
  • 1—Application structure
  • 2—Components
    • 2.1—Component structure
    • 2.2—Page and Layout structure
    • 2.3—Store structure
  • 3—SASS-usage
    • 3.1—SASS files
    • 3.2—CSS integration model
  • 4—UI library
  • 5—Form validation
  • 6—Component Cookbook
  • 7—Miscellaneous
  • 8—Milestones
  • Home
More Pages

New Wiki Page

Tip: You can specify the full path for the new file. We will automatically create any missing directories.