This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-27
Channels
- # announcements (47)
- # babashka (36)
- # beginners (7)
- # biff (34)
- # calva (9)
- # cider (5)
- # clj-http (13)
- # clj-kondo (24)
- # cljs-dev (9)
- # clojure (146)
- # clojure-austin (1)
- # clojure-europe (16)
- # clojure-nl (1)
- # clojure-norway (8)
- # clojure-uk (2)
- # clojurescript (4)
- # clr (1)
- # core-async (9)
- # cursive (11)
- # datomic (6)
- # emacs (17)
- # events (3)
- # fulcro (45)
- # graphql (7)
- # helix (1)
- # hyperfiddle (28)
- # java (1)
- # london-clojurians (1)
- # lsp (75)
- # malli (1)
- # membrane (35)
- # reitit (6)
- # releases (1)
- # shadow-cljs (48)
- # tools-build (5)
- # tools-deps (27)
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]}
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]}}}}
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.
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.
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
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
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...
Then what do you mean by “I packed all your fulcro libraries into one project which is the base of all my other projects”
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.
and override-deps
has never failed me, but I don’t know that I’ve ever tried it on transitive stuff
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.
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.
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
but in prod that lazy seq might expand after the dyn vars have been unbound, causing this error
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)
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)))
Ah, so the semantic UI helper is not forcing the lazy sequence. So that's the problem.
With parent context also does not force the lazy sequence, so wrapping with parent context won't help
In general, as you're seeing, I never ever use lazy sequences in the ui. They cause problems, and create overhead.
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
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
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.
And I don't know if @U9E8C7QRJ has the same problem in the other thread
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
I would be surprised if I don't mention it somewhere in the book though. I've been bitten by it myself, obviously.
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
So the book does talk about this exact thing in https://book.fulcrologic.com/#_factory_functions_for_js_react_components
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.
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. 🙂
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.
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.
I don't know @U9E8C7QRJ but he is pointing to breaking change in https://github.com/fulcrologic/fulcro/compare/2b96c84dff84b3..291b522d6fb519
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.