Style Guide & Naming Conventions - adobe/adobe-dx GitHub Wiki
Project Structure
In Adobe Dx, all artifacts / modules / packages are separated into their area of concern. To date, we have:
- Bundles - A common set of java classes for base functionality
- Apps/admin - A set of utilities to aide authoring and administration
- Apps/all - A content package to rollup all Dx dependencies
- Apps/content - A set of components and code to support content components (marketo, etc.)
- Apps/docs - A set of components and templates to support the Adobe Dx documentation site.
- Apps/structure - A set of components to support structure components (Flex, Page, etc.)
There is an expectation that all app modules have a consistent project structure that also descend into finer areas of concern. For example, admin:
Admin Root
admin/app (Content Package)
admin/app/pom.xml
admin/app/package.json
admin/app/webpack.config.js
admin/core (Java Bundle)
If we explore the app content package further, we can see these finer areas of concern in the jcr_root folder:
admin/app/jcr_root/apps/dx/admin/clientlibs
admin/app/jcr_root/apps/dx/admin/components
admin/app/jcr_root/apps/dx/admin/content
admin/app/jcr_root/apps/dx/admin/services
This translates in AEM to:
/apps/dx/admin/clientlibs
/apps/dx/admin/components
/apps/dx/admin/content
/apps/dx/admin/services
We can also go deeper into areas of concern:
/apps/dx/admin/clientlibs/author
/apps/dx/admin/clientlibs/configs
/apps/dx/admin/clientlibs/manager
/apps/dx/admin/clientlibs/registry
/apps/dx/admin/components/configmanager
/apps/dx/admin/components/datasource
/apps/dx/admin/components/datasource/contextawaredatasource
/apps/dx/admin/content/config-manager
/apps/dx/admin/services/encryptValues
Clientlibs
If we have the following clientlib structure:
/apps/dx/admin/clientlibs/author
/apps/dx/admin/clientlibs/configs
/apps/dx/admin/clientlibs/manager
/apps/dx/admin/clientlibs/registry
This should naturally translate to the following categories:
dx.admin.author
dx.admin.configs
dx.admin.manager
dx.admin.registry
In cases of specific component needs, each component should have a modularized clientlib category:
dx.content.marketo.publish
dx.content.marketo.author
For Webpack, the following entry names would be used:
module.exports = {
entry: {
marketoPublish: [`${PROJECT_PATH}/marketoPublish/src/js/app.js`],
marketoAuthor: [`${PROJECT_PATH}/marketoAuthor/src/js/app.js`],
},
}
Please not the camel casing as this is a Javascript file, so we are using Javascript naming conventions.
It's not required to have an author clientlib for every component, but it's important to illustrate how this should be organized if the need is there.
Clientlibs in Components
Bad
/apps/dx/content/components/marketo/clientlib
Good
/apps/dx/content/clientlibs/marketo
Putting a clientlib in a component is considered an anti-pattern and should never be done. All javascript should be funneled through Webpack, eslint, Babel, and Jest to ensure they follow Adobe Dx style guide and test coverage can be evaluated.