Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2024-03-13

Channels

#missionary
<
2024-03-13
>
awb9907:03:23

I have two ideas that I want to share here: idea 1: add a config to sci-configs to allow missionary to be used in a sci-clojurescript environment. This would make it possible to use all missionary features in the browser without having to do any cljs compilation. This will allow to build very advanced ui interfaces. Hoplon/Javelin which allows one to build a dag of cells has already been "ported" https://github.com/babashka/sci.configs/blob/main/src/sci/configs/hoplon/javelin.cljs When I say ported .. all what needs be done is make some adjustments to macros because macros work different in an interpreted environment. It should really only take a few hours to do this adjustments.

leonoel21:03:37

I support this, despite my very limited knowledge of sci I filed an issue https://github.com/leonoel/missionary/issues/104

Dustin Getz20:03:38

@UCSJVFV35 said by DM that he might attempt to implement the sci config (@UCSJVFV35 please correct me if I misunderstood)

awb9902:03:49

I have one question: missionary in cljs will need some kind of dom bindings. I studied the ones in hyperfiddle .. and unfortunately the namespace is interlinked with the server-side dag. So nothjng I could hack add quickly. Is there some other lib other than hyperfiddle else? https://github.com/kennytilton/matrix/tree/main something like matrix <-> webmx ?

awb9904:03:48

So had a good look at missionary .. missionary is easy to convert to a sci context. But cloroutine is hard or impossible to convert. I am not sure that cljs.analyzer can be converted with sci. Thats somehow against the point of sci I think. But then if cloroutine macros are only used in the implementation of missionary .. then thia macros will not need to be created. But if they need to add state to the analyzer cache at runtime .. then this state for aure ia not preserved im sci.

leonoel08:03:29

@UCSJVFV35 FYI I do not plan to keep the cljs analyzer dependency in the long run. We only use the very first stage of the analyzer and we don't need to interact with the cache. If we can do macroexpansion, desugaring and var resolution without it, then sci support may indeed be straightforward

awb9915:03:59

Cool! When do you think the analyzer will be removed?

leonoel20:03:06

not planned yet, but contributions are welcome

awb9907:03:56

My idea #2 is that there should be something less integrated than hyperfiddle. Something similar to holon-javelin. Just reactive dom elements in the browser. While all this implementations are already in electric it might make sense to have them separately packaged with the focus just on client side reactivity. Im combination with idea 1 this would allow to create ui functions that work even without an electric server running. For example it could be used to interact with rest services that are not related to electric. In any case it might be a good place to create reuseable reactive frontend components. I am watching the progress of electric with amazement - its a great showcase how true innovation runs in clojure land. But I have not seen big electric apps yet; and for now I think its a safer approach to be able to separate backend and frontend concerns more strictly so that ui does not leak into the backend. Also it would be easier to integrate to existing apps. Comments welcome!

👍 1
👀 1
Dustin Getz23:03:17

single-site electric will likely happen naturally as the technology matures, i believe we have some test suites that run like that though it is not an officially supported configuration.

💯 1
awb9907:03:02

I should add to my idea #2 that this might be a good way to introduce hiccup syntax to missionary. Because it is just frontend it will be possible to express html as hiccup and not as code like electric does. (No need to wait until electric has stable apis).

leonoel20:03:43

if you want to be able to render arbitrary html as data you'll need a reconciler, that's a very different thing

J09:03:26

Hello guys! To test missionary code in clj what is the strategy? Block the test runner with m/? or use an other lib to do async testing? This not work with the default clj runner: 

(deftest foo
  (let [async (m/sp ...)]
    (async
      (fn [_] (is (= 1 1)))
      (fn [])))

leonoel15:03:07

I don't see anything wrong with blocking m/? in tests

👍 1