A small description how your workspace should be.
App
This is the main of the application. Here you add all your pages and layouts.
Components
Here are all the base components of the template.
Configd
All the configurations of the application are done here. Such like Firebase | paths | theme | app.
Database
All the calls you can do to your Firebase
Features
All features that you create to work standalone such as a chat.
Languages
The language JSON's you can provide for the translations in app.
Layouts
All your page layouts in one folder. Creates nice structure.
Providers
All the magic happens here. These are all the encapsulations for the app. Such as the app(screensize listener and more), language, theme(sets all the css variables), notifications(adds in app + push notification functionality), authentication(provides a client side authenticator to get the user)
Middleware
If needed you can add middleware here.
Public
The public assets folder.
Sections
All sections needed in pages.
Styles
All CSS files for the project.
Utils
All the functions that can be reused in the app. Such as parsers and more.
Widgets
All reuseable complex components in the app such as avatar with label.
.env
The current local environment file. For security reasons.
Layouts are top layers of pages. Here you can create a layout that is consistent over all the pages inside of it. The folder with layouts is to add your custom layouts too to the folder. This helps with structure in your workspace.
Pages are the top level of the application. A page should not use the client side. Only the components inside the page would need that. A page should be SSR (server side rendering). This because we can fetch data from the server side and pass it prepared in the page. This would improve load time for the initial load. Once the page is active on the client you can create a stream in the client side of some components to have realtime updates.
A section is a part of a page or the whole page but that needs some client code to run. Like a stream of data for that part of the page. Or you need client side functionality such as eventlisteners.
A widget is a more complex component that uses multiple components or handles some functionality. These widgets are complex components but that can be reused on other parts of the application. Such as a custom card to show a component. This can be used on other pages too.
These are the lowest base components. No functionality is passed here but only the needed one. Like an avatar only has a picture or not. A avatar with a badge should be a Widget. The components are base parts of the application and mostly rendered on the server side. Only for some not.
All base components are styled in a scss file. This provides a way you can edited them as you like. And they can be overriden in a module.css file on specific demands. Styling is related to CSS files. This causes a nice separation of functionality/structure and styling.
We have not the possibility to use a variant in a media query in CSS. So '@media screen and (max-width:var(--breakpoints-small))' is not yet possible. The template already provides this possibility for the future. In mean time there is a alternative way. By adding the screen type to the body element in HTML you can now type 'body[screen-type:'small'] .classname1' and this will apply the class to the element if the screen has type 'small'. Keep in mind this is not 'smaller than' but 'exact'. So for medium size you need to add this too. <br/> <br/> With scss this is possible to add all subclasses inside of this parameter like: body[screen-type:'small'] .container-page { .section-1 { ... } .section-2 { ... } }
For pages and others you can add your module.css files inside the styling folder.