Fork me on GitHub
#rum
<
2017-02-26
>
mruzekw01:02:26

Is it possible to add arbitrary methods in mixins?

mruzekw03:02:33

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

tonsky07:02:15

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

tonsky07:02:31

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

tonsky07:02:58

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

mruzekw13:02:08

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

tonsky13:02:21

It probably could

tonsky13:02:14

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

tonsky13:02:31

Not using JS is a feature

tonsky13:02:25

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

tonsky13:02:49

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

mruzekw14:02:31

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

mruzekw17:02:47

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/

mruzekw17:02:24

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

tonsky17:02:47

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

asolovyov18:02:56

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

asolovyov18:02:41

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 🙂

asolovyov18:02:34

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

mruzekw19:02:17

@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.

mruzekw19:02:44

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

mruzekw19:02:43

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

tonsky19:02:06

No that's the recommended way

tonsky19:02:46

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

tonsky19:02:10

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

martinklepsch19:02:52

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

martinklepsch19:02:59

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

mruzekw19:02:32

@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.

martinklepsch19:02:45

@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

mruzekw19:02:12

Do you have an example by chance?

martinklepsch19:02:27

@mruzekw I don’t unfortunately

martinklepsch19:02:38

(rich-render {:simplified x :rich y})
x could be a rum component that can easily be rendered on client and server y could be “the real deal”, e.g. some complex React components

martinklepsch20:02:08

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.

martinklepsch20:02:35

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

martinklepsch20:02:40

(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)

mruzekw20:02:19

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

mruzekw20:02:54

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

mruzekw20:02:57

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

mruzekw23:02:29

I have something working 🙂