Dart frontend organization

[BenBlaisdell]

I've been doing more research into angular and how the frontend is organized in order to make adding new features easier in the future. Right now there seems to be a decent amount of duplicate js and html that could be turned int abstract templates and initialized with a specialized controller for each entity.

How states currently operate (omitted non-relevant lines)

.state('app.entities', {
    views: {
        'content@': {
            template: '<h3>choose an entity from the navbar :D</h3>'
        }
    },
})
.state('app.entities.engines', {
    views: {
        'content@': {
            templateUrl: 'static/partials/entities/engines.html',
            controller: 'EnginesEntityController'
        }
    },
})
.state('app.entities.datasets', {
    views: {
        'content@': {
            templateUrl: 'static/partials/entities/datasets.html',
            controller: 'DatasetsEntityController'
        }
    },
})

What I'm thinking

.state('app.entities', {
    abstract: true,
    views: {
        'content@': {
            templateUrl: 'static/app/components/actions_view/entities_view.html',
            controllerAs: 'entityCtrl'
        }
    }
})
.state('app.entities.engines', {
    views: {
        'content@': {
            controller: 'EnginesViewCtrl'
        }
    },
})
.state('app.entities.datasets', {
    views: {
        'content@': {
            controller: 'DatasetsViewCtrl'
        }
    },
})

Passing the controller with entity-specific data into the abstract create button and entity table

<dt-entites-table ng-init="init(entityCtrl)"></dt-entites-table>
<dt-create-entity-button ng-init="init(entityCtrl)"></dt-create-entity-button>

This would make it much easier to add features to general entity tools in the future. Disclaimer: I'm not sure if my controllerAs trickery in app.entities will work as intended, but that can be easily moved into child states if it doesn't.

@dannymcpherson, @maybeiambatman suggested I talk to you before spending too much time on this. Is there a reason you went with the current implementation aside from ease of initial setup, and do you have any comments/critiques of the route I'm thinking of trying?

[dannymcpherson]

@BenBlaisdell - It's been a while since I've looked at this code. I vaguely remember choosing the current format because it seemed like a nice way to deal with page layout in general.

Can you help me understand more about "This would make it much easier to add features..."? I guess that's the key question. Some guiding principles I used when writing dart initially were:

1. code discoverability
2. explicitness
3. code reuse

Will the refactoring support these values?

[BenBlaisdell]

1. Absolutely (in my opinion). The current structure actually runs counter to most angular best practices I've seen.
2. Not sure what you mean by this.
3. My main goal is to improve on this point. Most controllers and directives that deal with specific entities have a common structure that I've started to abstract into base entity controllers and directives. One specific example is the table directives. It will be easier to iterate on the ui if only the base dt-entity-table needs to be updated to add entity-agnostic features instead of ten different concrete entity templates and controllers.

[dannymcpherson]

Sounds good.

FWIW - If I could do this all over again, I would try to use react + redux... Assuming there is a json-schema-form equivalent :)