Fork me on GitHub

How do you usually deal with hiccup coming over the wire for rendering? Wrap it in Sablono?


sending markup from the backend is usually a bad idea, can you tell more about the use case you are facing?


Agreed. Data is queries, comes to state, is possibly morphed by post-mutations (or logic in the UI) and is directly rendered. But let’s say you have a need to generate arbitrary UI on the back-end (I have a client that does this for dynamic forms). In that case we have an HTMLNode component with a recursive :children ... query. The forms are designed/persisted in a database using a dom-like data structure that matches this.


persistent “data nodes” are part of that query (e.g. the HTMLNode has a {:entity (get-query Entity)} join, where the Entity just has * as it’s query (it is there for normalization of entities). Since any number of entities can share the same ident, 40 diff html nodes that all have data for a single entity end up populating the whole entity. Then it’s just (for some value of “just”) a matter of merging the two (html structure and data nodes) on the back end during the ui population query.


Sure, we’re storing scientific articles and displaying them as results of search queries. Abstract and full text are serialized as hiccup for storage. The original source is XML, but who wants that?


A nicety off the Reagent family was of course that it’s just a matter of joining this in (in a “data is data, I don’t care where it came from” type of sense). But alright, so on the backend, I’ll have to recursively walk the hiccup and invoke HTMLNode. Sounds like a job for Specter.


Ah, I see…you already hve it in hiccup. In that case there’s nothing wrong with using that on the front-end


Sablono should work fine…it emits React elements


I saw in the Sablono docs that only HTML5 attributes are supported. Given that they originate from XML, that’s no guarantee. I might have to sanitize them.


But basically, I can just treat them as a giant value and render them? I have no need to query on their internal structure.


for this specific case it may be a good idea to render on the server, you can render the hiccup there and get the HTML, considering its articles I believe you won't need much dynamic things on it, so just dropping the HTML there may be more efficient (not much point on making react render it if the content is not going to change)


For the time being, this is true. I have experimented with more interesting behavior, such as providing on-hover definitions or on-click navigation for interesting nouns.


Everything in Fulcro rendering is just plain React. Any js lib or cljs lib that emits React elements will work.

👍 4

If one is trying to move from FC2 (pre react16) that is based on figwheel to FC2 (react 16) or FC3, should I try and update the tooling first and then the framework? Or is it possible to keep figwheel?


I no longer develop using figwheel, but there is nothing in F3 that precludes using it.


Anyone working with React Native: I just got an expo example running with F3. Had to do a minor patch to mount. 3.0.2-SNAPSHOT on clojars will work.