I rebase many times a day, or switch branches, I seem to break my build whenever I do. I get weird errors, usually with broken JS output or similar. How can I resolve this?

I'm guessing there's no debounce or something

@dominicm I’m pretty sure there is a debounce

maybe its not long enough?

do debounces go into a queue? They should wait for the previous build to finish, if they don't.

https://github.com/bhauman/figwheel-main/blob/master/src/figwheel/main.cljc#L257

I'll look at what throttle does :)

it basically says if there are no changes in 50ms

then continue I think

right, so no prevention of overlap

So your build has to be <50ms otherwise 💥

no between each file change

Let me re-read, I must have misunderstood

that's not my interpretation of it

it runs on the assumption that the time between files changes is small and if it’s exceeded

hmmm

yeah, I'm still reading it as not be a debounce. It basically just sleeps 50ms from the first event coming in.

https://github.com/bhauman/figwheel-main/blob/4c651b7fba2889494c73a106f8ded64c061898b9/src/figwheel/main/watching.clj#L41-L56 fyi

I should double check my terminology, I know there's a distinction from debounce/throttle, but I forget repeatedly

https://css-tricks.com/the-difference-between-throttling-and-debouncing/

yeah, this has 2 big bold definitions. This is a throttle: > Throttling enforces a maximum number of times a function can be called over time. As in “execute this function at most once every 100 milliseconds.” except 50ms

> Debouncing enforces that a function not be called again until a certain amount of time has passed without it being called. As in “execute this function only if 100 milliseconds have passed without it being called.” This is what you described

yeah it should be named debounce

Hmm, no. I'm saying the name is right. It behaves as a throttle?

dang that algorithm is hard to read first thing in the morning

ok yeah I guess it is a throttle

Either way, neither prevents overlapping builds.

thats true

You'd need a lock or queue to prevent that.

wait a second

hmmm OK yep

this should be easy enough

Great. 😁

@dominicm

(defn throttle [millis f]
  (fn [{:keys [collector] :as ctx} e]
    (let [collector (or collector (atom {}))
          {:keys [collecting? events]} (deref collector)]
      (if collecting?
        (swap! collector update :events (fnil conj []) e)
        (let [events (volatile! nil)]
          (swap! collector #(-> %
                                (assoc :collecting? true)
                                (update :events (fn [evts] (vreset! events evts) nil))))
          (future
            (f (cons e @events))
            (Thread/sleep millis) ;; is this needed now?
            (swap! collector assoc :collecting? false))))
      (assoc ctx :collector collector))))

@dominicm deployed the fix to 0.2.10-SNAPSHOT

thanks for prompting me on that

hum, that doesn't look right to me. Doesn't that call f straight away?

yes but it works

well I changed it

(defn throttle [millis f]
  (fn [{:keys [collector] :as ctx} e]
    (let [collector (or collector (atom {}))
          {:keys [collecting? events]} (deref collector)]
      (if collecting?
        (swap! collector update :events (fnil conj []) e)
        (let [events (volatile! nil)]
          (swap! collector assoc :collecting? true)
          (future
            (try
              (Thread/sleep millis) ;; is this needed now?
              (swap! collector update :events (fn [evts] (vreset! events evts) nil))
              (f (cons e @events))
              (finally
                (swap! collector assoc :collecting? false))))))
      (assoc ctx :collector collector))))

when collecting? is true things get collected, and f is blocking

ah, so it cleans up at a different time, nice. Subtle.

less machinery and relying heavily on the properties of atom

Does the event list grow forever? I just noticed that.

(swap! collector update :events (fn [evts] (vreset! events evts) nil))

sets it to nil

relying on swap to grab the current events and delete them atomicly

ah, I see. And then any that come in during f will be collected and in the queue for later, great!

yeah it was right there, I guess I was tired/lazy when I was initially coding it??

so similar to the original version

There's a lot of considerations to factor in this little function. State is really hard.

Those 15 loc are thick with meaning.

can’t argue with that

but its really nice to have that fixed

@admin055 I got rid of the dependency on create-react-class so that’s no longer a problem

I’m now going to install android … which I was avoiding until now

@bhauman Perfect, thx for the information.

> Thanks for trying this out @admin055 > I really need this early feedback to work out the last bugs.  Sorry I > didn’t try this with android.  It’s such a large setup time. it's always a pleasure to use and test your work. I'll retry today later and let you know.

Thx @bhauman, all works perfect on Android emulator for me now. For Android emulator and real devices, we must only do on more command: adb reverse tcp:9500 tcp:9500 to get access to:

heck yes!

Last night it was too late i didn't even think about that! :)

Android real device test checked ✔️

oh really wow

Would you want to add android notes to the react native figwheel docs?

Yes of course

awesome!

also you may want to try the :launch-js configuration and see how it works?

especially if when you stop figwheel and relaunch

without closing metro or android

it should just work

@bhauman > Would you want to add android notes to the react native figwheel docs? PR done. > also you may want to try the :launch-js configuration and see how it works? Work perfectly, nice work!

This is fantastic! Great!