metasoarous
commented
8 years ago I think we actually do need this. I forgot that multimethods don't work particularly well as reagent components, because they don't trigger updates when you reload code :-(
So we'll need to build a dat.view/register-representation function that abstracts the api for us. This will be nice for all the reasons mentioned above, and also let there be representation middleware :-)
Details pending, but while I'm thinking about it, the easiest thing to do is wrap an r/atom that tracks the representations and then derefs them when called (perhaps using reactions and representation middleware) to keep all components from having to rerender when we just change one representation.
A cool thing about this is that it opens up the possibility (which won't be supported at first anyway) of having multiple representation functions for different parts of an app! Of course, then you have to pass around the object that you explicitly, but maybe there's a nice way to organize this?
Right now represent is a multimethod, and extensibility of datview involves defining custom methods. We should think about how we can make this more flexible and polished. Like, when you register one of these things, you should be able to register it with documentation, and specs for the context mapping. And maybe we can use a macro to do all this as well as define a var form of the component for convenience. Lots of questions here about how we can do this...