Inspiration from Mayhem?

[dylans]

While we've taken a very different approach to application architecture than we were first planning with Mayhem ( https://github.com/sitepen/mayhem ), there are a few things it did well that we may want to consider addressing somewhere in Dojo 2 (some/most are likely already addressed or not relevant, but trying to make sure we're not ignoring good ideas we had that should exist in a future version of dojo/app perhaps):

• Testing through dependency injection and mocking... for example, with a single configuration line in an app, you could switch the entire app from using real data sources to a mock data source, e.g. https://github.com/unifiedinbox/openinbox/blob/master/src/app/main.ts#L2 )
• Security (user auth, login, logout, isAuthenticated, checkAccess, other information about a user, and some form of RBAC)
• Routing ( I believe our router in dojo 2 is more than sufficient)
• Configuration overrides/inheritance (the approach for how to extend/override good defaults such as the router was pretty elegant)
• Data modeling (business logic, use of models to define structure of data in stores, as well as data validation and persistence)
• Constructors (all parameters for all constructors were a single kwArgs object, the idea being that Constructors could always be extended in a backwards-compatible manner, since new properties could simply be added to the list of accepted properties without a signature change)
• Event handlers... everything that is event driven returns a handler with a remove method, and then APIs exist to mass remove event handlers
• Consistent object destruction (e.g. all objects were destroyed by calling object.destroy, which would handle any cleanup needed)
• Standardized paths within applications for certain modules, e.g. app/models, app/routes, app/widgets, etc. (basically provide good guidelines for consistent app development)
• Application creation: instantiate an application object with custom configuration. Main purposes of the application object were data binding, overall application error handling/diagnostics, i18n, router configuration (navigation and state management), event scheduling, ui container, and user authentication and authorization (which would allow the app to determine things like which widgets could be displayed)
• Common run method for all things to start them
• View manager to switch between html, native, and other things like svg or webvr while sharing common APIs and interfaces (I think this is achievable with how we've designed Dojo 2, but obviously not put to practice yet)
• Somewhat of a DSL for templating and defining application views, html with various commands... I think we have this covered, just differently
• Pointer events support

[sebilasse]

@dylans Regarding

Security (user auth, login, logout, isAuthenticated, checkAccess, other information about a user, and some form of RBAC)

What I did the last month (in TS and with help of dojo2) • user auth, login, logout

• [x] OAuth1
• [x] OAuth2
• [x] GPGAuth
• [x] MailAuth
• [x] IndieAuth (incl. several enhancements) [for flow see https://indieauth.com]
• [ ] SMSAuth
• [ ] OpenId

• isAuthenticated, checkAccess next step after creating visual components

• other information about a user

• [x] SiteParser
• [x] MicroformatsParser (based on the brilliant Glenn Jones' stuff)
• [ ] SILO Parser (vendor specific things)

• RBAC this is currently actively discussed in the indieweb community ...

Tell me if should send something.