Fork me on GitHub
#re-frame
<
2022-05-31
>
Oliver George06:05:17

Hello. Is there any reason to worry that a recent version of re-frame would not be compatible with an old version of reagent? I have a big old app which uses react v15 and currently uses reagent 0.7.0 but I want to bump re-frame

Oliver George06:05:21

(upgrading react will mean a lot of testing and js component version bumps... will take a while to untangle safely)

Oliver George06:05:10

Didn't immediately crash - just looking for any general wisdoms about compatibility.

superstructor07:05:06

It is not well tested with old versions but re-frame doesn't generally have tight bindings to reagent that would change much between releases. Your own reagent code might be more likely to need attention if changing React or reagent versions. The only thing that comes to mind that I'd be wary of is re-frame-10x and re-frame-tracing (and thus also re-frisk as it is based on the same code) as it monkey patches re-agent internals and is very much tied to specific React/reagent version ranges.

superstructor07:05:42

By 'your own reagent code' I mean views, where your using reagent APIs directly. I.e. not re-frame dispatch or sub calls etc.

Oliver George11:05:06

Thank you. That’s giving me some confidence.

colinkahn19:05:35

We're trying to upgrade our version of re-frame-10x as well as Clojure(Script) to 1.11. There seems to be a dependency issue though caused by the inlined garden dep in re-frame 10x. See this issue, which resulted in a merged PR - https://github.com/noprompt/garden/issues/194 But garden hasn't had a new version released since March 2020, and we can't exclude / point to a SHA for the latest garden because the dep is inlined in re-frame 10x. Is it possible to release a new version of re-frame 10x that somehow addresses the issue, making it use the latest garden code available in their git repo?

superstructor20:05:07

@U0CLLU3QT Thanks for reporting this. Yes it is possible. Please raise a bug report in re-frame-10x. We will fix it but it is unlikely to be high priority as 1. does not break a build or project/user code, although I ack console noise is bad it is just a warning that can be ignored until fixed - unless I misunderstood something ? 2. inlining deps is a slow, manual process if MrAnderson is still throws in 10x's situation. Maybe MrAnderson has had updates which would make this a lot less painful. We inline deps in 10x because, as a dev tool, it is aiming to have no collision with your own project's dependencies. So although this warning is something to fix, inlining itself is a good thing that lets users use whatever version of things that 10x uses independently without breaking 10x and without 10x breaking your code.

colinkahn20:05:32

@U0G75S29H thanks, I'll open a ticket. To be clear, this does break our build. You would think that the shadowing of abs would be a warning, but it completely fails to compile, at least using shadow-cljs for us.

superstructor20:05:22

@U0CLLU3QT Thanks. Ok I misunderstood. That is very high priority then, since it breaks compilation. We will fix it as soon as we have time available.