Wanted: Real-life usage examples

[ITsvetkoFF]

Thanks for your generator with such a strong component approach!

But it seems that there is a lack of examples/approaches on how one can build real-world large app using it. Are there any?

Let's discuss some questions:

1. Where to put services/factories? What if this service is used all along the app? And What if it is used only in 2 components?
2. How far can we go with the flat hierarchy of components? (in a project structure). Wouldn't it be just great to have so-called 'dumb components' alongside so-called 'container components'?
3. Having *.scss files in every component is cool, but how can I use for instance global scss variables in every component? (maybe this can help, or other propositions?)

[bdurrer]

Just my two cents after my third [smaller] project using the lazy generator.

public example, albeit not large: https://github.com/bdurrer/calendarizator It's my own opinionated approach. I would go for more structure on a bigger app (and when I am not the only commiter).

1, 2: Putting every service/factory in it's own file goes without saying. Next time I would introduce extra folders for those. However, things which are only relevant for a single view/component, I like to keep contained there. The generator does not support custom subfolders out of the box (yet?), but you can move stuff into subfolders easily. You have to change the paths in the states.json manually.

3: What keeps you from including some global scss in every component's scss?

[MarijnMensinga]

split folders (2)

• It would be nice when the 'state components' and the 'normal components' are split by folder.
• It would be nice if substates were saved in the parent state folder. This makes it easier to find code in complex application structures.
• Components should be able to have subcomponents

src
|- states
|  |- application
|  |- home
|  |- settings
|  |  |- application
|  |  |- users
|- components
|  |- dashboard
|  |  |- graph
|  |  |- video
|  |  |- clock
|  |- table

Not exposing all states ui-router-extras future has the capability to load future states based on knowing only the level of states. It would be nice if this could be implemented by the generator. So states.json only contains the first possible sub states (e.g. in example above: home, settings). Then there must be a states.json for every state containing only the next substate (e.g. in example above: for home: empty; for settings: application, users)

This way, only the next possible states have to be exposed to the client and not all possible states.

[ITsvetkoFF]

@bdurrer, @MarijnMensinga, really useful suggestions! I have an idea to add splitting/nesting components to this generator.

@matoilic do you have own ideas, as a creator? :)

[matoilic]

Thank you all for bringing in ideas on how to improve and extend the generator :).

@ITsvetkoFF

1. I usually create an "api" component where shared services live. This is also the component responsible talking to the backend.
2. The generators already have support for nesting components with the --prefix option. I just extended the readme to list the available options for each generator. So far they were only documented in the help option. That makes it possible to group component types into different subfolders.
3. You could create a component that just holds shared styling resources. The src folder is within the include paths of the SASS compiler. This way you can import a shared variable file like @import "shared/variables";.

@MarijnMensinga

This structure could also be achieved with the --prefix option (see above), including nested / child components. As for splitting the states.json file; this is something we could introduce as a configuration option for the application generator. I wouldn't want to force this behaviour as it's mainly a question of preference.

[ITsvetkoFF]

@matoilic thanks for the surprise!

As for

src
|- states
|  |- application
|  |- home
|  |- settings
|  |  |- application
|  |  |- users
|- components
|  |- dashboard
|  |  |- graph
|  |  |- video
|  |  |- clock
|  |- table

structure proposed by @MarijnMensinga ... note that there are 2 separate folders:

• components
• states

Such style is not supported right now, I suppose (because application is in components folder)?

And one more architecture question/note from me: Am I right that in order to use some component in some state I need to import index.js of that state to my state index.js and also add component's module name to the state module dependencies? Maybe it is an overhead in usage ES6 modules (that actually work) in conjunction to Angular modules (that actually sucks)?

Maybe it is better to export the component's module name also? so that we could refer the module name without hard-coding it?

[matoilic]

Putting the application component is not supported currently. I'm thinking about to extract the application component into an own generator to enable such a structure as suggested by @MarijnMensinga.

As for the module usage; yes, you're right. To use a module you need to import it and also declare it as a dependency on the module where you want to use the component. The module that gets exported with the current approach already exposes its name in the name property. See https://github.com/matoilic/angular-lazy-workshop/blob/master/src/components/index-state/index.js#L14 as example.

[MarijnMensinga]

Since this discussion mentions many different topics I have written some proposals:

• #22 Proposal: separate application component and states from components folder
• #23 Proposal: bundle sub components with component
• #24 Proposal: don't expose all possible states

[matoilic]

Thank you such much for the proposals. I'll be on vacation the next weeks and start implementing the new features after that.

[samagit]

Hi, I'm developing a angular app that has to wet-boew as the unique UI skin with a specific theme. However this library and its themes are not part of npm registry. Also the only way to use it (according to the doc) is statically in the main index.html exemple:

<!--[if gte IE 9 | !IE ]><!-->
    <link href="../lib/theme-gcwu-fegc/assets/favicon.ico" rel="icon" type="image/x-icon">
    <link rel="stylesheet" href="../lib/theme-gcwu-fegc/css/theme.min.css">
    <!--<![endif]-->
    <!--[if lt IE 9]>
    <link href="../lib/theme-gcwu-fegc/assets/favicon.ico" rel="shortcut icon"/>
    <link rel="stylesheet" href="../lib/theme-gcwu-fegc/css/ie8-theme.min.css"/>
    <script src="../lib/wet-boew/js/ie8-wet-boew.min.js"></script>
    <![endif]-->

---

<!--[if gte IE 9 | !IE ]><!-->
  <script src="../lib/wet-boew/js/wet-boew.js"></script>
  <!--<![endif]-->
  <!--[if lt IE 9]>
  <script src="../lib/wet-boew/js/ie8-wet-boew2.js"></script>
  <![endif]-->

any clue how to lazy load/bundle such library or include it in the build process using the current generator?

Thanks

[michelcve]

How's the implementation of Marijn's proposals progressing matiolic?

I would love to see those changes make it into the generator.

[michelcve]

Is this project dead?

[matoilic]

No it's not. I'm working on an update to replace SystemJS and JSPM with Webpack 2 and to add the missing / requested features. Since I'm doing everything in my spare time it takes a while to get everything ready.

[michelcve]

Good to hear! I appreciate your work, and that you're devoting your spare time to this project.

Looking forward to the changes you're making, thx!