-
Notifications
You must be signed in to change notification settings - Fork 3
Code Structure
The entry point for the code is in src/main.js (if bundled, this will be referred to by index.html through build/app.bundle.js).
This script only serves to handle any immediate setup code. Any app-specific resources should be handled in the appropriate Application file.
This handles any module-specific interfaces. Modules serve as a template for a session to register and handle specific logic. Rendering components, services, managers, and other handlers are registered, initialized, and destroyed here. However, this is static and therefore should not save state across uses (only save state into session). In other words, this serves as a global template that persists over multiple sessions and acts on different session instances.
Modules are also loaded asynchronously and compartimentalized into their own bundles. This means that any module loaded is (and should be) completely independent of other modules.
Every module must be “registered” in FlapJSModules to be visible to other modules (and the app itself). If your module is not yet ready for production, you can disable it with a disable: true property.
These are the rendering objects of the app. For every component, it should have 5 files:
- The
.jsxReact component. This handles the structure and logic of the component. - The
.module.cssCSS stylesheet. This contains the localized style of the component. - The
.spec.jsJest test. This is the unit tests for the component to validate functionality. - The
.stories.jsStorybook test. This is the integration and UI tests for the component to document and validate the component working in its intended environment. - The
.mddocumentation. This serves to further explain the motivations of the component and any possible failure points that future developers should be aware of.
These are modularized “features” that is intended for ease of development when building modules. When multiple modules are implementing the same feature, it should be extracted into a service, and then included from the module object. They can handle logic, as well as state and rendering. They pretty much act as a small module (a module is basically a collection of services plus a custom module service).
This handles any app-specific resources. Unlike session-specific details, it handles actions or mechanics applied globally through multiple sessions. More specifically, it handles the modules’ lifecycle.
This handles any session-specific resources. Any data and state used by a module are kept here for a user-session. In other words, each session serves as an instance of a module workspace. There can be multiple sessions that are initialized and destroyed in a single “use”. And since there can be multiple sessions with the same module, this means you SHOULD NOT USE GLOBAL VARIABLES TO MANAGE STATE IN MODULES! Only save state to the session context.
What should be in each directory?
This includes all miscellaneous documentation that do not belong in src.
TL;DR All other documentation.
This includes all scripts or tools used to manage the project (not used within the app itself). These usually should not be edited but can be contributed to for more utility.
TL;DR All scripts or tools to manage the project files.
This includes all production-ready distributed files. These files should never be edited as the directory will always be replaced on build.
TL;DR All output files. DO NOT TOUCH THIS!
This includes all generated code coverage output files. These files are automatically handled by the project and therefore should not be edited manually.
TL;DR All code coverage output files. DO NOT TOUCH THIS!
This includes all source files that make up the project. Any code, assets, etc. directly related to the app should be within here.
TL;DR All your editable source code and assets.
This includes all static assets that will be used by the app. Things such as images, language files, and global scripts. Files in here usually should not be bundled with the app itself, unless closly coupled with that code.
TL;DR Put everything that is not app code and style in here.
This includes most of the code that pertains to the UI components that make up the app. This should have not only the source code that will run the component but also the tests and stylesheets.
TL;DR All your component code, including scripts, tests, and styles.
This includes all of the code that belongs to specific modules. Each module has its own subdirectory named by its module id. The files within these directories can range from more UI code to module specific assets. There is not enforced file structure beyond the module parent directory, so each module should have some sort of description to explain themselves.
TL;DR All module-specific code has their own subdirectory under here.
This includes all tests that do not belong elsewhere. This usually means tests that span multiple scripts or utility test functions.
TL;DR All miscellanous tests that do not belong in components.
This includes all utility files that do not serve any of the previous purposes.
TL;DR All utility functions usable globally.
This includes all deprecated code. Try not to use this if you don’t have to.
TL;DR All deprecated functions to be avoided at all costs.