Fork me on GitHub

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


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


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


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


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


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


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


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


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


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


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


each remote gets it’s own queue


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


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.


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


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)


that’s a good point. according to this you can share the scriptengine instance but we may need to use separate bindings for each thread


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


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.


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