Fork me on GitHub
#fulcro
<
2023-02-27
>
janezj12:02:20

I wan't to include local copy of fulcro into my project. com.fulcrologic/fulcro #_{:mvn/version "3.6.1"} {:local/root "../fulcro/fulcro"} And the error:

Error building classpath. Unable to compare versions for com.fulcrologic/fulcro: {:mvn/version "3.0.6", :deps/manifest :mvn} and {:local/root "/home/jj/workspace/fulcro/fulcro", :deps/manifest :deps, :deps/root "/home/jj/workspace/fulcro/fulcro"}
I 'removed' all other references with com.fulcrologic/fulcro-native {:mvn/version "0.0.10" :exclusions [com.fulcrologic/fulcro]}

tony.kay15:02:37

Try an absolute path instead of relative?

tony.kay15:02:34

you should not need to remove the other references. I Have an alias in my global deps.edn (~/.clojure/deps.edn) that looks like this so I can just turn that on/off at will with an alias:

:aliases {
           :f3-dev         {:override-deps {com.fulcrologic/fulcro {:local/root "/Users/tonykay/fulcrologic/fulcro"
                                                                    :exclusions [com.taoensso/sente]}}}}

👍 2
janezj16:02:09

Same error when changed from relative to absolute. This global alias is very nice trick. I have to figure out how to use it with calva/shadow setup.

janezj17:02:49

I packed all your fulcro libraries into one project which is the base of all my other projects. So override with alias is not working. And for developing in this base project the override is super useful. And I know that I was able to include rad via local/root. But not now.

tony.kay19:02:23

with shadow, just add -A:f3-dev to CLI options

tony.kay19:02:29

don’t use Calva myself

tony.kay19:02:25

Combining multiple libraries into a single one (which has a single coordinate) will cause you problem. Don’t do it. There’s no way for your dep analysis to know that your “monster” lib has all the other things in it

tony.kay19:02:33

The only way to do that cleanly is to vendorize it (e.g. rename all the nses to something you own, and make a new MVN coordinate for it), but that will break when you go to use other libs that want Fulcro. Just don’t do it. You’re making a ton of crap work for yourself that is pointless and will break things

janezj19:02:02

I am not building a monster lib, but a set of resolvers, middleware and and some ui stuff, and a side effect is that I am referencing rad, i18n, semantic ui wrappers, http kit, ring...

tony.kay06:02:50

Then what do you mean by “I packed all your fulcro libraries into one project which is the base of all my other projects”

tony.kay06:02:12

You mean you’re making a new artifact, like com.yourname/fulcro-base which is a library of resolvers, middleware, etc. whose deps refer to the various fulcro dependencies? If that’s what you meant, then yeah, that’s fine.

tony.kay06:02:16

and override-deps has never failed me, but I don’t know that I’ve ever tried it on transitive stuff

tony.kay06:02:04

more of a Clojure tools.deps question

janezj17:02:39

I am porting to react 18. And I found that my app is not working in advanced mode and with-react18: main.js:4709 ERROR [com.fulcrologic.fulcro.components:787] - A Fulcro component was rendered outside of a parent context. This probably means you are using a library that has you pass rendering code to it as a lambda. Use with-parent-context to fix this. It works when I remove with-react18, without warnings or errors.

tony.kay19:02:34

React 18 may do things async where 17 didn’t. Sounds like you might be using something in such a context which should be wrapped with with-parent-context. I’ve ported a pretty large app to 18 without issue.

janezj20:02:38

But why just in advanced mode? Tomorrow I will try with source maps.

tony.kay21:02:09

timing changes when you do adv compile. For example, in non-adv mode a lazy seq might get forced due to error checks at the react layer that are not present in dev mode

tony.kay21:02:31

but in prod that lazy seq might expand after the dyn vars have been unbound, causing this error

tony.kay21:02:53

using map inthe UI is a common cause of that, esp if you don’t use my UI functions and macros (which try to force lazy expansion no matter what)

👑 2
tony.kay21:02:34

(e.g. if you were using a hiccup notational add-on)

janezj11:02:09

mapv is ok (sui/ui-table-body {} (mapv ui-station stations)) force-children is also fine. (sui/ui-table-body {} (comp/force-children (map ui-station stations))) Interestingly it is NOT working when with-parent-context (sui/ui-table-body {} (comp/with-parent-context this (map ui-station stations)))

tony.kay15:02:32

Ah, so the semantic UI helper is not forcing the lazy sequence. So that's the problem.

✔️ 2
tony.kay15:02:08

With parent context also does not force the lazy sequence, so wrapping with parent context won't help

tony.kay15:02:37

Only the low level dom stuff does the forcing.

tony.kay15:02:39

In general, as you're seeing, I never ever use lazy sequences in the ui. They cause problems, and create overhead.

tony.kay15:02:52

But you are pointing out things that the library can help with. I'm totally open to making with parent context Force lazy sequences, though the semantic UI wrappers are very thin wrappers over low-level react stuff, and you should never ever use lazy sequences with them

tony.kay15:02:37

It isn't advanced compilation that's hurting you, it's the fact that in advanced mode you end up using the optimized version of the react library

janezj15:02:16

I checked in the book, and there are several cases where map is used, I didn't know till now, that this is such a major problem.

janezj15:02:02

And I don't know if @U9E8C7QRJ has the same problem in the other thread

danieroux15:02:07

Yes, this is the same problem

tony.kay15:02:05

It doesn't surprise me that the book sometimes uses it. I wrote that quite a while ago, and was only thinking about usage within the Dom functions, which autocorrect this problem

tony.kay15:02:35

I would be surprised if I don't mention it somewhere in the book though. I've been bitten by it myself, obviously.

tony.kay15:02:07

So I guess one patch would be to fix the book up to include a strong statement about lazy sequences, and then correct all the examples

tony.kay16:02:46

and the example you’re giving is in fact a react component whose factory was code generated for you. That said, I’m going to update the book to stress lazy sequence rendering issues, and how Fulcro auto-fixes some of them for you.

janezj16:02:50

Yes, I understand it right know. And I read this chapter a few times, but it just slipped out of my mind. Or to be exact I never understand it. The problem is that it worked till react-18. 🙂

tony.kay16:02:27

which is odd because I’ve had problems with it since I started (React 15)

danieroux17:02:09

Same here, we've been chugging along fine with the code as is, until react-18

danieroux19:02:51

I have not been able to isolate this yet (it is on a background thread): We run Fulcro 2b96c84dff84b3, the one before "Change back to using dyn vars instead of React context". 291b522d6fb519 breaks for us with the same error.

tony.kay06:02:05

Your statements make no sense to me. I have no idea what “same error” is.

tony.kay06:02:50

Or are you a co-worker of janezj and are trying to talk about that issue?

tony.kay07:02:00

I have no further things to say about with-parent-context kinds of errors. My best guess is either lazy sequences or some other pattern that causes late evaluation of a fulcro factory.

danieroux12:02:43

Yes, what @UQ5QFFX54 says. @U0CKQ19AQ apologies for an unclear and incomplete report. I'll work on isolating it some more. What I know now: • Our code in advanced compilation runs fine in 2b96c84dff84b3 using with-react18 • Using 291b522d6fb519 with advanced compilation we see the error "A Fulcro component was rendered outside of a parent context", using with-react18 • This happens in a specific part of our app, and I have not yet taken the time to get a small repro of it.