# Angular Route Schematic ## Background With NgModule-based schematics users have the ability to generate a lazy loaded module which generates a route in the closest module or the specified module. This logic will need to be implemented for standalone applications, but under the name of module does not make sense. Therefore we should create a new schematic to generate routes for standalone applications. This design document is intended to discuss the API and functionality of this new schematic. ## Overview The new schematic should be named `route` and will be run via `ng g route` ## What should the schematic do? - new route folder - `[name].component.*` files (ts, spec.ts, html, css) - `[name].routes.ts` file containing child routes (optional) - add a route configuration to a parent routes array to point at either: - child routes file - a child component ## What information is needed? - route name (same as child folder?) - lazy flag (default value?) - flag indicating if routing to a single component or a child routes array - should child routes array point to the generated component? (likely yes) ## What should the API look like? - project (string optional) - the project the route is associated with - if not specified use (in order) 1. current working directory 2. default project defined in the workspace - name (string required) - the name of the route to be generated and associated components - path (string optional) - The path at which to create the new route, relative to the workspace root. - url (string optional) - value to supply to the generated route definition - this value would default to the `name` option when not supplied - parent (string optional) - where the route should be defined - this would parallel the `module` option in the module schematic - default value would be the routes array in `src/app/app.routes.ts` - children (boolean optional) - flag indicating whether the route points to a component or a routes array - default behavior? - lazy (boolean optional) - flag indicating if the route definition is a lazy route - default behavior? ## Questions - if project type is "application" it should be standalone? - what if project type is "library"? - not with this initial implementation ## Is this a worthwhile implementation? Background to this argument: Years ago when schematics were initially implemented we had a discussion about providing a routes schematic. The outcome of that discussion was to not implement the routes schematic (obviously because it does not exist) due to the fact that the DSL/API or the schematic would require the same amount of typing in the terminal as it would in the codebase. So the value of learning the API provided very little value to the user over creating the route definition manually. I am not arguing that case, but feel that it should be discussed as prior to implementation.