Clojurians Log v2

@zackteo, we have found that a functional reactive approach can be very effective when dealing with mutable JS view objects like a Leaflet object: 1. Model all aspects of your Leaflet map as immutable data in your db. If you want to have multiple maps on the page, your db model has to support multiple model instances. 2. Bind your Leaflet object to the relevant dom node when the view component is created 3. Produce a subscription to your map's immutable data 4. Create a reagent reaction that updates the JS Leaflet object with the immutable data as input. There are two important restrictions: 1) your immutable data is your only input to the reaction 2) the only side-effects of the reaction are changes to your mutable JS object. Your Leaflet object effectively becomes a materialized view of your app db. The only way to make changes to your mutable Leaflet object is by transforming the immutable data in the app db. Reagent/re-frame will take care of keeping your mutable JS in sync with your app db.

@zalky did you use leaflet directly or react-leaflet ?

@zackteo, started with leaflet, eventually migrated to react-leaflet.

Oo, okay okay - I was wondering if the reverse might be needed but i guess react-leaflet is actually more than flexible

@zalky btw, by any chance do you have an example of this approach? If not no worries, I'll try to figure it out along the way 🙂

@zackteo, unfortunately I can't share the code, but there are not too many moving parts. Mostly using [:> Component props children ...] operators plus the update approach described above. I think as we moved to react-leaflet, we moved some of the leaflet mutations out of the update reaction, and just passed them as simple props to the react component (zoom, center, stuff like that). Maybe you've already seen this, but if you haven't, here is a very common pattern that is effectively the same thing as using an update reaction: https://github.com/day8/re-frame/blob/master/docs/Using-Stateful-JS-Components.md

Well, it's not exactly the same: with this approach, you do have to option of make your reactive update a function of two states. Potentially with this approach you can be more efficient and refined in how you update your mutable JS object, but it can be more complicated to reason about, and depending on your implementation, you can potentially lose some nice properties, such as time travel.

Thanks for your help!! 😄

No problem, good luck!

Reagent has reactions, a way to generate new cached state based on existing ratoms/reactions: https://github.com/reagent-project/reagent/blob/master/doc/ManagingState.md Regarding the "bind" part - attach a ref to the relevant React component, use that ref to get the DOM node and pass it to Leaflet. Reagent has some relevant and I would even say must-read examples in its repo on how to interact with React and JS components.

I don't really understand (isn't this what re-frame subscriptions do already?) - do I just wrap my subscription like so (reagent.ratom/make-reaction @(rf/subscribe [:results]))

Re-frame subscriptions are based on Reagent reactions. No need to wrap them. The only reason to wrap them is if you want to add some computation to them. But even then - it's better to have a proper subscription for it.

hmmm, okay, in that case reagent.ratom/make-reaction isn't what I want right? Since I have re-frame I think my issue now is that I believe I am using a subscription correctly, but it is not re-rendering the component.(leaflet map)

So to force my leaflet map to re-render, do I have to wrap my map component with reagent/create-class as in here? https://github.com/day8/re-frame/blob/master/docs/Using-Stateful-JS-Components.md

I can't answer that question because I have no idea what your current code is doing.

okay - maybe ill create a minimal example

When you use reagent/create-class, you create what's called a form-3 component. They're useful for interacting with JS components, but are not truly necessary because we also have form-2 components and reagent.core/with-let which often can be used instead.

Before you create a minimal example, I still urge you to go through the relevant Reagent examples. And write a simple Leaflet app without re-frame so that you aren't compounding points of failure.

A learning process should be gradual, not in the "let me tackle it all at once" kind of way.

Thanks for your help @p-himik. I actually have been using re-frame already so I don't think im compounding points of failure per se. It's just that the repo I'm working on is private cause it is my final year capstone project with a company. I already did a simple example in pure reagent to display a geojson area on my map. Whereupon I moved it into my initial re-frame db state and it still displays. So now the step I'm taking is to be able to click a button and change update that part of the db. Which does work. But it does not update the map

> to be able to click a button and change update that part of the db > it does not update the map That should work in the Reagent app as well. If you haven't tried it there, then the example is too minimal. :)

And I'm just trying to figure out how to make the map reactive in that sense. But the jump from normal components to having to create my own stateful component seems quite big. So I'm trying to understand how to best accomplish this re-rendering of the map

Please go through the Reagent examples. Everything is there. This is a very popular use-case, so it has been thoroughly documented and tested.

Okay I'll try doing so again! Tho my past attempts have been a bit confusing. Especially because I'm not exactly sure how to apply it to leaflet instead - I'll try coding it out

After doing that, try creating such a Reagent example yourself, but for Leaflet and with a button that updates the state. No re-frame, only Reagent. If that works, then you're all set and it should be trivial to switch to re-frame after that. If that doesn't work, link that example here and I'll take a look.

Alright! Thanks for your help! Honestly reagent/clojurescript stuff can come across as pretty daunting compared to clojure. Perhaps particularly because I have some slight js/react experience but not nearly enough, and none with setting things up from scratch

Sure thing. Indeed. React by itself is enough for a novice to feel daunted. Adding Reagent with ClojureScript in top certainly doesn't help. :) That's why learning gradually is important.

@zackteo, I think p-himik provides some good advice. A strong understanding of Reagent will come in real handy building any kind of Re-frame app beyond simple examples. The only thing I'll add is to draw your attention to two important things about https://github.com/day8/re-frame/blob/master/docs/Using-Stateful-JS-Components.md example. 1. Notice that all the updates to the mutable javascript object (aside from the initial creation) happen in a single update fn in the :component-did-update lifecycle method. The question then is, where does this update fn get its data? The answer is you have to build out an immutable data model for your map in your re-frame app (in the example it would be single set of coordinates). Your event handlers update this immutable model in your db, and then your subscriptions ( :current-position in the example) get that immutable data to your update fn. create-react-class on its own doesn't help update your map, unless you close out the whole event handler -> immutable data -> subscription -> update fn loop. 2. Notice that the mutable JS object is isolated inside the view component gmap (atom nil). Because it is mutable state, it is tempting to try updating it directly via event/effect handlers. While this can work, you lose some important properties of your system, one of them being that mutations on your JS object produce view changes directly, and break the MVC isolation that Reagent/Re-frame try to impose. Instead, the https://github.com/day8/re-frame/blob/master/docs/Using-Stateful-JS-Components.md approach isolates your JS objects as part of the view, and makes them a function of the immutable data provided by your subscriptions. This is similar to how the stateful DOM structure is a function of the data from your subscriptions, and not something you manipulate in your event/effect handlers.

https://github.com/zackteo/leaflet-example I couldn't figure out how to use make-reaction or reaction for now. I put just used an atom directly and that won't re-render the map. Am not sure what my train of thought should be on how to get my leaflet-map to re-render

Will continue when I wake up tmr :x

I had to change your code a bit so it loads. Your GeoJSON is wrong.

Apart from that, react-leaflet is not a good wrapper - it does not respect data changes of already rendered components. To fix that, add ^{:key @state} in front of [GeoJSON ...].

Here's a simplified and fixed version of your code. I used a simpler GeoJSON feature just because it's easier to see with it that it works.

(ns leaflet-example.core
  (:require [reagent.core :as r]
            [reagent.dom :as d]
            ["react-leaflet" :refer [MapContainer TileLayer GeoJSON]]))

(def point [-104.99404 39.75621])
(def geojson {:type     "Feature"
              :geometry {:type        "Point"
                         :coordinates point}})

(defn leaflet-map [state]
  [:div
   [:> MapContainer
    {:center (reverse point) :zoom 11
     :style {:width "1000px" :height "1000px"}}
    [:&gt; TileLayer {:url "//{s}.<http://tile.openstreetmap.org/{z}/{x}/{y}.png%22|tile.openstreetmap.org/{z}/{x}/{y}.png">}]
    ^{:key state}
    [:&gt; GeoJSON
     {:data (clj-&gt;js state)}]]])

(defn app []
  (r/with-let [state (r/atom geojson)
               move-left (fn [state]
                           (update-in state [:geometry :coordinates 0]
                                      (fn [x]
                                        (- x 0.01))))
               move-left! #(swap! state move-left)]
    [:div
     [:button {:on-click move-left!}
      "Move point left"]
     [leaflet-map @state]]))

(defn mount-root []
  (d/render [app] (.getElementById js/document "app")))

(defn ^:export init []
  (mount-root))

@p-himik Strange, am certain my geoJSON is correct - but I do have this weird situation where the app won't "compile" until I save. But anyhow, I got it working! 🙂 https://github.com/zackteo/leaflet-example/blob/master/src/leaflet_example/core.cljs I do however have some questions, 1. ^{:key @state} , how might I know I would need to do something like this? Is there documentation that I can look at ? o: 2. I tried using reset! to change my geoJSON from a small square (geojson) on the left to a giant triangle on the right (other-geojson), I don't quite understand why the map will only re-render if I first change it to nil is this something to do with what triggers the re-render?

Regarding GeoJSON being incorrect - it very well may be that it were simply my own experiments that were incorrect. And during my prior experience with GeoJSON, I always used feature and feature collections as the top-level objects. But seems like the spec allows having the geometry at the top level as well, so all is good. 1. When you use the same @state in a :div and in some component, and the latter is updated but the former is not. It means that the component has some issues in its state management or it simply disallows changing at least some of its state for some reason. Providing the :key metadata (or via a regular attribute, if the component itself supports it, like all the plain HTML entities) makes sure that when that key is different, the whole component is re-rendered. One thing to note - that key is stringified when it's used. 2. I blame it on the GeoJSON component's implementation. It has nothing to do with Reagent.

Is the :key metadata is a HTML thing? or is that regular attribute ? Is there a link I can read up on this? :o I guess there's why in some example they wrap react-leaflet with some of their own structure https://github.com/instedd/planwise/blob/f7fde4e1d17c7aaba82357de7b8a8b1492440ec0/client/src/leaflet/core.cljs

Right there's this https://github.com/reagent-project/reagent/blob/c214466bbcf099eafdfe28ff7cb91f99670a8433/doc/FAQ/ForcingComponentRecreation.md . But what is a regular attribute ? :o

It's a React thing. Despite most of the documentation mentioning lists of all sorts, it's applicable outside of lists as well. • https://reactjs.org/docs/reconciliation.html • https://reactjs.org/docs/lists-and-keys.html Planwise doesn't use react-leaflet. It's the problem with react-leaflet, not with leaflet itself. There are two ways to use :key in Reagent:

^{:key something} [:div {:class ...} ...]

[:div {:key something, :class ...} ...]

Okay! Thanks for all your help!! 😄 Appreciate it

Good summary of the problem… and interesting ideas. The project at hand being a hobby I'm under no pressure to make this work; just found it to be a good occasion to take a first stab at SSR. As I've said: I've already gotten this to work: 1. Endpoint receives a request containing app state (as b64 query-param) 2. Set Re-frame to that state (via multiple dispatches) 3. Render SVG-component via reagent.dom.server/render-to-string 4. Convert SVG to PNG and save to disk 5. Redirect to the static PNG (with 302) – works with crawlers. Steps 2–4 are skipped if an image for that particular state already exists. My only remaining worry is about concurret requests: What if another request comes in during 2. Could the DB-Atom be reset by handler B dipatching against it while handler A is still building the state it wants to render. Whith a global DB atom I smell trouble, but this is hard to test – maybe there would be no issue. With my current project there wouldn't be, since I get a couple of hunded reuqests per day at best – but in principle? If I ran this on an actual server rather than a shared hosting limited to a single node runtime I could just add another node build, that starts no server at all but only takes the encoded state and spits the PNG to disk. The handlers would then just shell out, run that node script and then redirect to the resulting PNG. This would separate the Re-frame instances – but, again, I'd like to find something more elegant, even if it's less brutal than firing up Puppeteer all the time.

Re-frame acts on a queue - no handlers are run in threads. So no handlers can run in parallel. However, workflows can run concurrently if they consist of multiple events - when handling an event results in dispatching another event via some means.