Clojurians Log v2

@tony.kay regarding om-css with advanced optimisations.

In development mode and simple optimisations when i do (pr-str Component) I get a string namespace/Component but with advanced optimisations I get #object[$U "function (){React.Component.apply(this,arguments);this.state=null!=<http://this.cc?this.cc():{};return|this.cc?this.cc():{};return> this}"].

ohh small gotcha. I had :pretty-print false so it removed pr-str.

@claudiu so it works now?

@tony.kay Spoke to soon. most of mixed up the builds and thought it worked.

As a simple test #?(:cljs (js/console.log (prn-str Root) (pr-str Root))) seems to work on dev, simple but not for advanced compilation

I’m not sure why we’re talking about pr-str

I thought you had some question about the css support working with advanced

ah, from an earlier message. I see. You’re saying that the generated CSS classnames are getting messed with during advanced compilation

That is probably a bug with om-css. There is probably some other method of getting the component name that doesn’t work the same when adv compilation is used.

In advanced compilation the artifacts are going to be renamed and minified. But I would not expect this to break anything.

yep strange one. Tried it on a clean chestnut template:

(defui Component
  Object
  (render [this]
    (dom/div nil "test")))
(js/console.log (prn-str Component) "" (pr-str Component))

behaves exactly the same 😞

on clojurescript slack someone suggested that it might be related to this issue: https://dev.clojure.org/jira/browse/CLJS-1249

not sure

the function in question is https://github.com/untangled-web/om-css/blob/master/src/om_css/core.cljc#L22

we just need to figure out what the “right way” is to get that string…it is prob not pr-str

yes 🙂 untangled/om-css is exactly what I was looking for, and the new pull request seems really nice.

yeah, I’m excited about the improvements

eliminates duplication and simplifies usage

Does anyone know of a good tutorial on creating “switcher” components via union queries that isn’t based on Untangled?

The Untangled in the Large videos on YouTube walk you though how it is built

the HTML5 routing video

identical to Om Next

other than you have to write the parser that handles the data reads

The bit that’s tripping me up is figuring out which parts of the behavior are coming from the untangled-specific initial state stuff

@claudiu So, it looks like if we use the React displayName that will survive advanced compile…I’m trying it now

Ah, so it’s not expected that the default db->tree would be able to resolve something like this?

initial state works for Om Next

Untangled’s parser IS db->tree

and InitialAppState composes a tree to Root that IS what you’d pass to Om Next

I would not dream of using Om Next without InitialAppState

Right

eliminates so many headaches with about 10 lines of code

it really is just a protocol

and a getter to support SSR

Yeah. I’m inheriting some non-untangled code and figuring out what’s salvageable

And trying to figure out why we didn’t just use untangled 😛

oh…I lied

InitialAppState for unions has a helper function to add in union initialization

which is what you’re tripping over

that function would work with stock Om Next too

Will take a look. Thanks!

I’m biased, but not sure why more ppl aren’t using untangled 😜

guess I’m not advertising enough

tony.kay: my guess would be that people take some time to realize that Om.next by itself is very bare bones, adding Untangled creates more layers than people are used to, maybe we should make a survey, hehe

Yeah, I’m thinking the pitch should be something that helps people understand that. I think people see Untangled as something completely different, as opposed to something that makes Om Next easier

@tony.kay was merge-alternate-union-elements! the helper in question?

yep

it walks the query and uses declared INitialAppState for find the “extras”

@claudiu Try om-css version 1.0.2-SNAPSHOT

I don’t remember why, but there are CSS tests for augmenting via a defrecord…not sure those will work right in advanced…but not sure why they even exist

I think I was thinking you might want to make namespaced CSS without defui (use defrecord instead)

I’m going to play with that and see if it still works, but the new version should fix your problem

Yeah, I don’t think I can make that one work. So, defrecord support will not work in advanced compilation…use defui instead (you don’t need a render method on a defui). I doubt anyone is doing that, but it is an easy fix.

Om-css version 1.0.2 pushed. Fixes advanced compilation