Custom elements support

[Deraen]

From #198

@mike-thompson-day8 My plan is to use Compiler interface to allow replacing the method used to create elements, so user can handle custom tags there. Could work even now by creating custom compiler with make-element which handles certain keywords, something like:

(defn make-element-custom [this argv component jsprops first-child]
  (let [component (case component :custom foobar-component component)]
    (tmpl/make-element this argv component jsprops first-child)))

Though make-element has to return React element directly, so that could be too low level for this. As-element / vec-to-elem could be better level to handle Reagent elements.

https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/template.cljs#L296

But the Compiler interface and tmpl functions aren't (yet) part of the public API, so they could still change.

This isn't very simple, but I think this will be advanced feature and it doesn't need to be simple to use.

I'd also like to hear what is the usecase in Re-frame from custom elements.

[mike-thompson-day8]

@Deraen
My goal for re-frame is to make hiccup even more about data than it is now.

First, I'd like to have views registered ... here's a simplified version of that:

(reg-view                   ;; <-- part of the re-frame API, like reg-event-fx
  :some-view-id           ;; <-- this id is used in the next code fragment
  (fn [arg1]              ;; <-- this is the renderer
     [:div  "hello" arg1]))

And then, later, I'd like to be able to use the registered :some-view-id in hiccup:

(fn some-reenderer
  [] 
  [:some-view-id  "world"])     ;; <-- keyword used instead of function symbol 

By removing symbols (for functions) from the first vector position, and replacing them with registered keywords, I want to make hiccup even more about data.

There is a variety of short term re-frame specific reasons for view registration, including injecting subscriptions as args, but the medium-term goal is to position re-frame for the coming wave of multiple tab applications which will be happening when SharedWorkers get wider adoption (which is now starting to happen, as I understand it ... but give it 18 months to become more widespread). Being able to transfer data between workers is a lot easier, than symbols. Bottom line is that more data-oriented is generally better.

In fact, although not the subject of this issue, I'd love to also figure out how to remove the other kind of function from hiccup ... those of event callbacks like :on-change ... which is another story ... but you can see where I'm going with this ... ideally I'd like hiccup to be 100% data ... in an ideal world.

Back to subject at hand ... I'd like to be quite clear ... I'm not suggesting that Reagent do too much here. It just needs to supply a way for re-frame to register "a keyword mapping function". This function would map from a keyword like :some-view-id to the associated component. At the moment, a function's symbol can appear in the first vector position of hiccup. I propose that if Reagent were to find a keyword there AND if that keyword was not one of the standard ones like :div, then it would call this registered mapping function (supplied by 3rd parties like re-frame) to obtain the associated component, and thereafter, Reagent would proceed as it does now. I'm absolutely not expecting that Reagent would do any registration stuff itself. That's re-frame's job. All Reagent has to do is see a keyword, call a mapping function to obtain a component, and then proceed as it does now.

[cj-price]

May be of some interest: https://github.com/cj-price/reagent-custom-tags-compiler/blob/master/src/main/reagent_custom_tags_compiler.cljs