UltraRangers / gauntlet

Gauntlet is a Typescript server template to kick-off your development fast 🔥🔥🔥
https://gauntlet-demo.herokuapp.com
MIT License
3 stars 0 forks source link

Client | move components to modules #42

Closed ghost closed 6 years ago

ghost commented 6 years ago

@jmaicaaan Let's discuss this tomorrow, I think we can make the client more like of what we have in server side, this is not refactoring just placing the components into its right position.

jmaicaaan commented 6 years ago

I think this would be good to make the client more like server structure

ghost commented 6 years ago

I will closed this now, I moved the components for client side into modules. We have 2 containers only the public and cms which handles the main routing for the modules. I would like to add another issue for investigating the shared module, I believe the shared module should only a single instance per page? but now we moved the components to modules, then the cms-module is likely imported the shared and also the login (for example) imported also the shared, and in an instance the cms acting only like a container then probably on a login page the shared module was instantiated twice, depends on the number of modules in a single page. But this structure really helps us to resuse components and I really like it coz it is somehow in a flat structure (not too nested :D ).

jmaicaaan commented 6 years ago

I also like the idea of flat structure which is kind of easy to navigate between things/components. But I have a question in these containers - cms and public. Why do we need to put it in a folder? To lazy load it? Looking at the app-routing.module.ts, both containers will be loaded already on start. Wondering 🤔

ghost commented 6 years ago

hmm now the cms and public are both container and a module inside the app so they were lazy loaded by the application container. Before we move those components into modules, we can see that on master branch, the default module for the app is the public module where the default component is the home component. But now since we can have multiple containers (cms and public or it can be marketing or other). So the app module will lazy load a container first (in our case the public) and the public container will lazy load a feature module.

ghost commented 6 years ago

ahmm only 1 container at a time will be lazy loaded, maybe the paths are confusing, really hard to explain the definition of containers. then that container will expose modules and lazy load it.

jmaicaaan commented 6 years ago

I think I get your point that the container will lazy load the specific component per route. The containers are there to initialize the base routes in which will be use to lazy load some components.

ghost commented 6 years ago

Yes that is correct, and the real reason we are supporting multiple containers rather than the single one which is the app container, is because the app will probably have mutilple environment specification. I think we faced this issue in MyFit on where the header of cms is really different on the marketing header. So we used flags and imagine if we will have another environment which is possible, another flag again.