So, I would appreciate a community cross-check here: I’m planning to add support to the DOM function to detect and auto-convert clj maps (so we can stop using #js…it’ll be optional optimization to use it). I’ve benchmarked the change, and it won’t hurt a thing. I’m trying to decide the answer to this: “Should I throw an exception if it isn’t nil, an object?, or a map??” I’ve never written code in Fulcro that would violate that assumption, but it might be technically possible to pass something to react that would work as props, but whose constructor isn’t js/Object

Thoughts?

@tony.kay you can just look at the argument in the macro. if its something it can identify as a map/js-object/nil it does the optimization in the macro. if not it falls back to "interpreted" mode and does the conversion at runtime. I do this in my react element wrapper. https://github.com/thheller/shadow/blob/master/src/main/shadow/markup/react.clj#L147-L164

do (dom/h1 {} ...), (dom/h1 nil ...) and (dom/h1 #js {} ...) are all "fast" and (dom/h1 foo ...) is slightly slower

should probably expand the checks to go the fast path for string?

@thheller So, you're right that that would cut overhead further, but the actualy measured overhead of the cond compared to everything else is soooo small I don't see it as being worth it. It wasn't even measurable in a statistically significant sense when compared to the overhead, for example, of React's VDOM->DOM stage. I think we're over-optimizing

and string is a legal thing to give props...not sure what you mean by fast path for string?

The one I did think of last night was undefined...that should be explicitly checked for in js since there are ways to end up with that instead of nil

@tony.kay the cond is done at compile time not runtime

so it does make a diff at runtime

its a macro writing a macro

If the cond is structure like this:

(cond 
   (or (nil? props) (object? props)) props
   (map? props) (clj->js props)
   ...)

as is object?

like in the single microsecond range

once you're to map? then you're doing a bit more, but you're about to do a conversion which is heavy anyhow, and you already took the overhead of the creation of a persistent data structure

I do know that cond is a macro, and that nil? , object?, and map? are not. I've read the source. I've done a lot of critical optimization in my time 🙂

no you misunderstand

the code I linked is a macro

No, I understood that

you're saying you can take that overhead at compile time

I agree

I disagree that it is worth the added code and complexity

I think it is over-optimization in light of the measured facts

I measured it and found a pretty high performance benefit

compared to a React VDOM diff?

(dom/div {:onClick foo} ...) vs. (dom/div #js {:onClick foo} ...)

oh yes, absolutely

so and thats whats the macro does. nothing more

it turns the first into the second

oh, I didn't see that

I didn't realize you could do that at compile time 😄

yep

ok, well, that is a hell of a useful thing 🙂

I sort of compromised on one things because of react v16 which is really picky about arrays in arguments

but still the conversion to a JS object is done in the macro

IF the first arugment is a map

for react v16 compat I generation a JS array and then call React.createElement.apply(nil, the-array)

since React.createElement("div", nil, some-array) caused warnings

JSValue is the trick. it is what the #js reader literal generates

and the compiler will then turn JSValue into plain JS instead of emitting a CLJS object (eg. map)

That makes sense. I had seen those before but kinda assumed they were for compiler internal use only

should be fine. I don't see them going anywhere.

what I meant by string? is that currently (dom/h1 "foo") will not use the optimized path but should

oh, I see. You're making the props map optional

yeah, more hiccup-ish

ok, perhaps I should steal your code 😉

ok with me 🙂

Thanks, I think this will make a big difference in people's perceptions. That #js thing is pretty annoying, as is peppering nil about as well. Like yours much better.

oh yeah the #js thing is horrible

I'm still not 100% happy with the solution though

I was thinking about bypassing React.createElement completely

https://www.npmjs.com/package/babel-plugin-transform-react-inline-elements

similar to that but if breaks if anyone is still using string refs

so React.createElement it is for now

and that is behind the scenes, so easy to do later or in another ns

and then we are probably entering over-optimizing territory 😉

yep

but what annoys me is the React.createElement copies the arguments we pass it

so that is super wasteful in my mind and I don't like waste 😉

anyways I left it there it works ok enough

better than all other solutions I found

nice @thheller !! thanks for that approach, sounds awesome :)

Also have to make that all work with SSR, since this all has to evaluate in clj as well.

I totally gave up on SSR. It just never works for me.

I personally lean that way as well, but many people have it as a required feature, at least for the top-level pages. Fulcro makes that pretty tractable, actually (as in I was surprised how easy it was to get it functioning when I wrote something non-trivial with it).

well, what happens if the user wants to use some react component? can't do that in CLJ?

Two approaches: you don't need it to "work" on the server, you just need it to "look ok", so a simple wrapper that outputs static content in clj is suffucient

JS react component, not defsc or defui

the other approach is to use Nashorn, but that one kinda sucks in overhead

I prefer the former

I don't buy the whole SSR is faster argument either. every benchmark I saw complete disregarded load time on the server

it's not perfect, but it's perfectly practical

no, not faster...I don't care about that either. SEOis the gotta-have

search engines have to see HTML, not just a blob of js

thats also not true anymore

google indexes JS just fine

if you stick to the rules that is

you sound like me a year ago 😜

I used to argue with people about this the same way...

I validated a bunch and the only thing I found to not work is structured data

I had not personally validated that google is now able to index js-generated pages

I did.

Bing?

who?

😛

ok I didn't test that

it's a big rabbit hole

but as a library author I don't want to limit my audience due to lack of a feature that is perceived as "necessary"

esp. since the code for it is already there and working 🙂

yeah I can understand that

@tony.kay @thheller this guy's stuff is what convinced me SSR is an exceedingly good idea (i used to be of the 'just serve a <script> tag' group): https://rauchg.com/2014/7-principles-of-rich-web-applications#server-rendered-pages-are-not-optional

it's not about SEO for me

https://www.youtube.com/watch?v=Ar9R-CX217o i think this talk discusses it too

and nowadays we have H2 push, which makes the argument stronger

Thanks @sundarj. I agree that the speed is improved by SSR, by quite a bit in some cases, and my earlier recommend of using placeholders (shells in your article) for things that cannot be SSR’d is exactly the level of SSR I shoot for when doing it now.

the only issue I have with this is the "fast server-side applications" assumption.

what if I need to do some actual work, db queries that say take 500ms

The shell solution works for that as well.. What you’re trying to do is give the user a feeling that something is there. It’s more about perception. Usability isn’t improved.

until everything is “there”, nothing works anyhow

and what I find most annoying is pages that look like they are finished but don't work because the JS hasn't finished yet

much rather see a loading anim 😛

well, I’d encourage there to be a loading anim in there 🙂

because I very much agree with you

I mean, just gmail’s loading bar is good enough for that matter

exactly. I just want to know that something is happening. seeing the empty page without anything happening is bad

seeing a logo alone buys you a second or so

ssr is definitely useful for some pages just not universally

yeah, it depends on how much you can know at request time

sometimes you can know enough to render the above-the-fold content fully (only matters that what the user sees is working), other times not

but SSR is an important tool to have at your disposal

suppose it's like macros in that sense 😁