Fork me on GitHub
#untangled
<
2017-01-02
>
tony.kay01:01:48

So, at present Untangled has not been touched up for server-side rendering (if that is what you're trying to do), though the underly Om library does support it.

tony.kay01:01:30

our stack is split into several libraries: client-side, server-side, database-related, etc

tony.kay01:01:00

cljs always compiles to js...so in production you just run a single js file

tony.kay01:01:58

Also realize that unless you've studied the theory of operation of Untangled/Om, you might not even be asking the right question. It's a radically different beast than REST-based UI kits

tony.kay01:01:06

during development, figwheel can serve as the server, but its primary purpose is to hot-reload code through a websocket

tony.kay01:01:44

Take a look at untangled-template. It is a full-stack template that will build and run out of the box, and you can play from there to see if it fits your needs.

sova-soars-the-sora02:01:00

@tony.kay Ah thank you, I didn't know all that much about figwheel ... so figwheel reloads code via a socket, that makes sense. Yes, I've been delving into how it all works, I was writing an application using Datomic and Compojure w/ Ring a couple years back, and now I'm trying to wrap my head around Om.next, mutations, reads, etc. I got very excited when I read about server-side rendering because I was still in a conundrum: do things the old-fashioned, laborious, and hard-to-maintain way to utilize html+js native speed on page load... OR use Om.next and so forth and have static references unavailable... But then finding out that there is server-side rendering changed the whole game for me. I'm still filling in gaps in my knowledge, so thanks a lot for taking the time to explain things.

tony.kay04:01:01

It really won't take much to make Untangled work with the server-side rendering. Mostly it's just making sure there are stubs for the stuff that appears in your program, but that would never get called on an initial server-side render

tony.kay04:01:28

I started a branch to do just that, since it has come up a few times.

tony.kay04:01:09

the hardest thing I've hit is the i18n, which will be a weak point: what if you want to server-side render based on browser locale? We'd have to have equivalent server-side rendering with server-side versions of the translation files. The latter is simply making them cljc...but formatted render is provided by the format.js library, so we'd have to figure that out. But, most of it will work with very little work.

sova-soars-the-sora05:01:53

Hmm. Cool. I don't have a need for internationalization currently, but that is great that the project is so open-minded to support that, stock. I have another question. I'm looking at an Om.next todo MVC that has the serverside rendering and there is a parser.clj and also a client-parser.cljc ... so I think for serverside rendering that means that there must be a read function implementation [aka parser] on the server-side (.clj) ... so in addition to templated pages to render, one also has to make sure om can get all the data it needs to do an "instantaneous render" of the page+data .... just sharing some conclusions out-loud

danielgrosse12:01:36

I have a question, regarding the step E_UI_Queries_and_State_Exercises in the dev guide

danielgrosse12:01:05

What do you mean with top-level properties and compose in the people widget?