Thinking in terms of web components is a little tricky. How am I supposed to handle all the ways an element can be abused? I don’t think I can, and even so, I’m probably to lazy to try.
I just need a simple REST API:
- To be able to handle individual items in a collection (Add/Remove/Interact)
- To be able to list the whole collection
Man, makes me think back to the Backbone.js collections. They were super easy to work with. Should I just create an element in the global context and let the individual elements deal with it? That doesn’t seem to be as composable, since then you couldn’t have two of the same rest api could you?
I thought of the following ways to handle these requirements:
- Make a global rest-api context that can be named. Naming them will avoid the first problem of composability. It still doesn’t seem to be the web component way though
- Make a global rest-api and have the elements reference them via a “source” attribute
- Make a global rest-api and communicate with events
- Make a local rest-api per element
There are too many ways to do this!
Making a local rest-api per element seems like it would lock you in to an api structure, or barring that would force you to proxy attributes and I don’t want to do that.
The global methods sound better to me, except that they are global. Maybe that isn’t a big deal, after all the datasource is pretty much global too.
Which of the global contexts would work the best?
If a use a named or unnamed rest api on the global context, then I’ll have to add an attribute to the children to tell them what rest api to connect to. That seems like something I’m not going to be able to avoid. Event the events would require namespacing.
Using a named source is kinda how I think the Polymer app storage thing works, and it will work for events or “source”ing. I think that might be the way to go. If database needs to be able to switched out when I find something better. Naming the sources and the elements that use the source will probably be the easiest to change.