I'll just leave it here: https://twitter.com/shaunlebron/status/835642675118424064

Is it possible to add arbitrary methods in mixins?

@mruzekw have a look at https://github.com/tonsky/rum/blob/gh-pages/examples/rum/examples/custom_props.cljs#L15-L33

Thanks! @misha

Is it true that server side components have to be pure rum? No 3rd party components?

@mruzekw arbitrary methods — yes, but you won’t have a way to access them :)

server-side — yes, pure Rum, we don’t run React nor JS on server-side

if you do run React on Node.js on server, then your server-side components can be any mix of Rum and React

Couldn’t the Nashorn engine be used to compile React components on server side?

It probably could

@asolovyov tried and was not satisfied with the quality of their implementation as far as I remember

Not using JS is a feature

You'll have to fight with JS engines memory leaks at the very least

This is a server, you can't spin up a new node instance for each incoming request

Fair enough. Just thinking of the best way to do server-side rendering given a react component. Sounds like I’ll have to reimplement the component in Rum

I’m trying to get a sense of what it would take to convert a react component to a pure rum one. For example, how would I convert: http://andrewhfarmer.com/detect-image-load/

What I’m stuck on is how to access state and modify from handlers like handle-image-loaded and handle-image-errored

why would you want to detect image loaded on a server? what would that even mean?

@mruzekw Nashorn is 1) slow to start up 2) much slower than regular JVM 3) very memory-intensive

in fact, it ate around 12-14 Gb of heap for my app a little more than a year ago, can't imagine what would happen now 🙂

before JVM server-side rendering I've actually switched to running pool of Node processes, because Nashorn was painful to use

@tonsky You’re right. It doesn’t mean much on the server. My goal is to get the <img /> tags to render on the server and client.

I feel like I’m missing something with regards to universal apps with Rum. How would you suggest architecting an app for it

Currently I’m literally using the same app component for both client- and server-sides. Is this not recommended?

No that's the recommended way

You can use reader conditionals though when you need much simpler version of a comp on a server

E.g. plain IMG tag instead of complex live React component on a client

@tonsky The issue with reader conditionals is that you then get differences at first render which react chokes at

not sure how bad this affects react perf in reality but it’s something highlighted as an error during dev

@martinklepsch I’ve noticed the error too, which is why I’m being careful to have the same tree on client and server. But that’s turning out not to be practical.

@mruzekw one approach could be to have a wrapper component that renders a simple component first and then “flips a switch” once mounted to show the new JS-based component

Do you have an example by chance?

@mruzekw I don’t unfortunately

(rich-render {:simplified x :rich y})

rich-render would have a :did-mount lifecycle handler that changes and atom (`rum/local`). Once that atom is true the rich component will be rendered.

This way you could initially render the identical simplified component and render the rich component once react has fully taken over the DOM

(I’m not say this is a good idea, you’ll need to try and see if it works. I skipped server side rendering when I tried it once I realized it’s not that simple)

Okay, I’ll give something like this a shot.

I think I may have settle with different trees (simplified or otherwise). I’m building an app where performance and SEO count, so server-side rendering is importnat

@martinklepsch Would your rich-render idea work with third party react components?

I have something working 🙂