balmas
commented
10 years ago I need to become a bit more knowledgeable about Angular. I have no objections in principe to using the Angular idioms to make development easier for the plugins we are building but I think we need to be careful about using it to take shortcuts in the communication between the plugin and the middle layer that externally developed plugins won't be able to take advantage of. I like the idea of using the history plugin to make sure we aren't too tightly coupling things as we develop.
LFDM
It's important to provide an API for plugins that do not want (or are not able) to depend on Angular. Right now the whole application doesn't declare any events at all. Everything inside of it is triggered by state changes (there might be exceptions, but generally this will hold true for everything that follows - which is very important to keep things simple).
This should be possible if we emit change events in the state service, which could notify non-Angular plugins on every change through a simple JS API. The currently important states are held in two objects:
state.tokensandstate.selectedTokens. If we allow external plugins to listen to this and to write information back, external plugins could do whatever they want - one function to get in and one to get out should be enough. As inside of the Angular application changes inside of the DOM are only triggered by state changes, listening from Angular plugins to external ones shouldn't be a problem at all.The configuration of plugins would therefore need to declare if a plugin is external or not, because external plugins have to be separated from the rest and listen to these specifically emitted events - their view logic is also different. Such plugins would receive a DOM element by the Angular application, as a place where they drop their HTML contents.
External plugins would always suffer from some drawbacks of course - which also leads to the question what integration with Angular would mean. It will be a little harder for them to react to events - this could be overcome if plugins provide at least a little service class that calls methods of the plugin but hooks them back into the Angular system. They would loose all the benefits on the HTML side. This might be the most amazing concept of Angular - directives, a truly awesome approach to deal with the problem of separating business logic and views, while staying totally modular. The development of this application will bring lots and lots of tiny little pieces that enable one to build complex but amazingly idiomatic applications through simple html templating. Example, a simple directive written this morning: If you want to select the next token of a text by clicking somewhere, all one has to do is to insert a
<next-token>element in an html template. You can style it anyway you want by defining the content of this element, but it would automatically just work and do what you want. Integration could therefore mean, that one has just to provide a different html template for their plugin. It could include everything it had as a stand alone piece, but enhanced by Angular directives. - This would be very hard to do if external plugins do not follow a clear separation principle for business logic and views, I guess this would be the biggest obstacle in making such a thing simple.Anyway, we want to provide the possibility of using totally Angular-agnostic pieces and should do this soon - if we run into troubles we shouldn't be too far down the road that changing things is too hard.
Another issue will address this issue in a couple of minutes as well.