Fork me on GitHub
#fulcro
<
2017-09-27
>
roklenarcic05:09:03

@tony.kay No I haven't managed to fix it yet. I'll start working on getting the whole code uploaded to github. It works without it, but it bugs me because I don't understand why it doesn't work.

jwkoelewijn07:09:47

Hi here: looking at the development branch of Fulcro I get the impression that multiple remotes are supported now?

jwkoelewijn07:09:07

The last comments I found about this were stating that it was something still left to do, but I managed to find some tests in test/fulcro/client/application_spec.cljs that make me think otherwise

jwkoelewijn07:09:50

could someone confirm this? I implemented multi-network support in an ‘semi-old’ untangled version, and was planning to port it to fulcro

jwkoelewijn07:09:26

given that I found some hints indicating support for multi-networks I think I’ll can spend my time a bit better 🙂

mitchelkuijpers07:09:33

@jwkoelewijn This is currently fully supported ^^ it is even added to the new defmutation macro. I don't use it myself though

jwkoelewijn07:09:05

like the implementation as well btw, using different send-queues

jwkoelewijn07:09:28

I used 1 queue and split the requests later, think I like this approach better

tony.kay21:09:55

@jwkoelewijn multiple remotes have been supported for a long time.

tony.kay21:09:17

the defmutation macros work with them, the load functions all accept a :remote parameter.

tony.kay21:09:41

if you use the multimethod technique of mutation, you use the Om Next style (key by remote keyword)

tony.kay21:09:08

each remote gets it’s own queue

tony.kay21:09:08

I guess I’m just confirming what has already been said…should read more before typing 😉

tony.kay21:09:44

With the help of @azeem it looks like Nashorn SSR is going to work. A little more to do, but we got a successful render from the compiled JS.

tony.kay21:09:02

When I time it (once it is started) it can render a frame in about 8ms

tony.kay21:09:09

and that one instance can be re-used with updated props to do general renders. I don’t know yet if the same instance is thread-safe…need to read more (e.g. can multiple SSRs be processed in parallel by one Nashorn instance. I suspect no)

azeem21:09:13

that’s a good point. according to this https://stackoverflow.com/questions/30140103/should-i-use-a-separate-scriptengine-and-compiledscript-instances-per-each-threa you can share the scriptengine instance but we may need to use separate bindings for each thread

azeem21:09:46

i’m not sure if there’s a lot of global state mutations, if any, that happen inside react. but we may be able to get away with it

tony.kay22:09:19

Sounds like you can (and should) share Nashorn instances, but that you can supply a thread-specific binding environment. So, that makes it pretty good.

tony.kay22:09:14

one-time overhead per thread at startup. So pooling SSR threads is trivial and efficient