Logical routes

[floriangosse]

I'm looking for a place where I can put my logical routes. We have some routes which are only communicating with the our server an redirecting to a specific state based on the response.

I have only one solution in mind which tries to keep all routes (components and logical) in one place. The idea is to move all routes regardless of which type into a folder called routes/. But keep the statefull components at the old location (e.g. containers/). That means that all routes which are defined for a component are moved into the routes/ folder and they define the statefull component as a dependency.

app/
├── containers/
│   ├── comp1/
│   └── comp2/
└── routes/
    ├── route1/        // Depends on ./containers/comp1
    └── route2/        // Depends on ./containers/comp2

What do you think about it?

[iangregsondev]

Is this not what Routed Components are for ? That was my understanding. I also had a similar question which I haven't posted yet. If routes are defined as a Routed Component then I was wondering on a naming convention for this ? A routed component is probably a page right i.e Home, About etc.. Each routed component would have other High Level components inside. These high level components would have low level components.

So I was wondering about how to name the routing components i.e. HomePage, AboutPage - with a page suffix?

I was wondering why you wanted to stored your routes separately and not part of a routing component ?

Maybe its something that I what to adopt. Although I like the idea of Routed Components just don't know the best place for placing these, if they are inside the components directory I would really like them to have a suffix or maybe inside a sub-directory so you can easily identify that these are in fact Routed Components.

[floriangosse]

Why I want to move my "route" part of the routed components into an own folder because I have some routes which have no component so no views and I want to have all routes (routed components and logical routes) at one place.

These routes do something like the following example:

$urlRouterProvider.when('/my-logical-route/:value', function ($match, $state) {
  if (isValueCorrect($match.value)) {
    $state.go('routed-component-1');
  } else {
    $state.go('routed-component-2');
  }
});

[noderat]

@floriangosse It sounds like the two components in your example are similar, and perhaps they would be nested together (like Common and Components) and you could define your routes at that particular level.

[floriangosse]

These two components have nothing together. E.g.: one component is secure-component and the second is not-found.

[iamdey]

I'm also a bit perplex with that "routed component" organization, I don't get why it should be in component folder instead of common or its own folder, sometime may be but not for basic routes. I mean, it does not make sense to me to have agnostic components mixed with very opinionated routed components (it's ok with 3 components but not 30).

Before refactoring I organized my components in 3 folders that follow our BEM convention and trying to make stylesheet classes similar to components:

• layout common components folder for .l-{block} stylesheets
• section routed components folder for .s-{block} stylesheets
• module. agnostic components folder for .m-{block} stylesheets

(I will probably keep this organization)

[toddmotto]

@iamdey Routed components are just smart (stateful) components with routing definitions. If a routed component has children, those are part of the same feature, therefore child components and likely mostly stateless components.

With regards to the component directory, consider these as your "modules" of features instead of components. Everything should be a component with regards to high level design of the structure of the app. Component = module (high level components, such as routed/stateful). Common modules are for application specifics, so would be extremely confusing to move routed components to application specific directories.

Routed components are modules of their own, or at least should be if part of the higher level routes, nested routes they would likely extend the existing module of that parent component.

The whole idea around feature modules/components is to make them agnostic of eachother, therefore you can pull out /components/dashboard and with little refactoring (perhaps for managing state/events) can be moved to any other app.

If I had a components/dashboard module, this will likely contain a root component that acts as a routed component and passes data to child stateless components. Therefore the CSS for them should be specific, such as <div class="dashboard"> as the base for that component - styling would likely follow the same rules as the components they follow, at least that's how I'd do it. React with CSS modules/inline styles, Angular 2 all take this approach as well. Hopefully we'll see some isolated efforts coming in Angular 1.x to allow for inline styles of some kind with CSS scoping that can be tied into a build process :)!

[iamdey]

Thank you @toddmotto to be part of the discussion.

If a routed component has children, those are part of the same feature...

You mean there are no shared components, well ok it's better to not have dependencies in the case we might want extract the routed component in order to be reused ... but it is very rare actually. And for maintainability it becomes a nightmare to keep consistency between high level components such as buttons, lists, links, forms... in that case.

Styling is boring me too, may be inline CSS may help. (This topic sounds like often skipped probably because everybody use bootstrap or their own styleguides.) Well, BEM sounds like a good candidate for styling components, it's more like composition over inheritance. It is ok when the component defines attributes for itself in the place it is allowed to, but wait, how to deal with responsive behaviors or sticky elements or anything I can't imagine right now.

[toddmotto]

Yeah! They can be part of the same feature. If you need "generic" components then this may well sit inside "Common" for example. Just heading up the runway for my flight so gotta keep this brief !

@toddmotto

On 8 Aug 2016, at 07:38, David Epely notifications@github.com wrote:

Thank you @toddmotto to be part of the discussion.

If a routed component has children, those are part of the same feature...

You mean there are no shared components, well ok it's better to not have dependencies in the case we might want extract the routed component in order to be reused ... but it is very rare actually. And for maintainability it becomes a nightmare to keep consistency between high level components such as buttons, lists, links, forms... in that case.

Styling is boring me too, may be inline CSS may help. (This topic sounds like often skipped probably because everybody use bootstrap or their own styleguides.) Well, BEM sounds like a good candidate for styling components, it's more like composition over inheritance. It is ok when the component defines attributes for itself in the place it is allowed to, but wait, how to deal with responsive behaviors or sticky elements or anything I can't imagine right now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[iamdey]

@toddmotto finally I follow your advices about the component and common folder and it works well (for now), I will be able to show that soon.

I think, I misunderstood the component module theory:

Component module A Component module is the container reference for all reusable components.

Well it is not "reusable" in the scope of the application. It's a full-feature component that might be extracted to be reused in an other app. In conclusion, it is the home of most of routed components. And so Common modules include agnostic/reusable components, coupled components ...

Then read again the styleguide and I think I'm still wrong.

Anyway. @floriangosse don't you think your routes are just part of app configuration? (I have change the initial topic, I'm sorry)