The re-frame-10x UI freezes when I reload the browser page, I donβt remember it doing it before upgrading to the latest versions of re-frame (1.2.0) and re-frame10x (1.1.4), though its possible its due to some other issueβ¦
If I clear out the reframe-10x items in LocalStorage, it creates a new 10x UI. But I wonder what I might be doing wrong that this behavior is happening.
Using shadow-cljs 2.14.5. I donβt have a literal main
but I do have:
:builds {:app {:target :browser
:output-dir "resources/public/js/compiled"
:asset-path "/js/compiled"
:modules {:app {:init-fn visx.dashboard.core/init}}
:devtools {:http-root "resources/public"
:http-port 8280
:preloads [day8.re-frame-10x.preload]}
:dev
{:compiler-options
{:closure-defines
{re-frame.trace.trace-enabled? true
day8.re-frame.tracing.trace-enabled? true}}}
...
Not sure if it might be related to the shadow-cljs config. The instructions mentions module
not modules
or might there be something I need to put in the init code for some shadow-cljs lifecycle?
@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 ...} ...]
and
[:div {:key something, :class ...} ...]
I'm not 100% sure whether the latter works if the component doesn't handle :key
explicitly. I just stick to the metadata way at all times.config looks fine. it is :modules
, where each entry in that maps defines a module
Okay! Thanks for all your help!! π Appreciate it
1πThat shouldn't happen @rberger. Do you have a minimal reproduction ?
Let me see if I can reproduce it outside our relatively huge and not public webapp. Its consistently failing there of course :-)
I need to send a few dozen requests to the server, but I would not like to do it at once, but divide it into packets
How can I e.g send e.g. 4 simultaneous requests and the next one only after all the previous ones have succeeded. How can I do this with re-frame-http-fx
?
I tried using async-flow
, but it seems overly complicated in this case and maybe there is a simpler way?
> implementing your own effect handler is somewhat tedious
Not at all, given that it will be a thin wrapper around :http-xhrio
. You don't have to reimplement the whole wheel, just add a couple of atoms to track the queued requests and the in-flight requests, and that's it.
@emccue I have currently created a similar ugly creation to yours, but I don't like it at all. As I mentioned, I tried to simplify it by using async-flow, but it made things even more complicated. Rewriting http-xhrio in my own fashion seems cool and minimizes the amount of code I need to write, because it's only a few lines
I would probably create a new effect handler, similar to :dispatch-debounce
.
Unfortunately, I can't quite picture it. After sending a request via :http-xhrio
the next queued events are immediately processed, including the next :http-xhrio
. I would have to throw calback to :on-success
, or make some kind of counter and call the event in a loop until the counter is released
Am I thinking right?
No. You would create your own version of :http-xhrio
that's based on that but has rate limiting added on top.
ah, I misread, now it's clear
thanks! I'll try it this way
1πIn general, this is another time when 5 minutes don't pass between my question and your answer. On the re-frame and reagent channel you are a one man army serially solving other people's problems. Appreciation. π
2πTry 1.1.7 please. It fixes several bugs. @rberger
(1.1.7 of re-frame-10x)