Fork me on GitHub
Tyler Nisonoff00:08:13

i could make a small repro repo if you’re interested, but assuming you don’t have the time to go through all that. Could be a good exercise for me to just verify its not something else funny going on in my app


not much time here…but could just be a bug of how I’ve done the search alg for the RAD routing helpers. You could make an alt form for standalone with diff name/prefix and add that to router as workaroudn

👍 1

there's a line that throws a warning from shadow-cljs in legacy-ui-routers.cljc: #?(:cljs (set! js/React react)) I removed it in my own code and stuff seems to work ok. PR wanted?

------ WARNING #2 -  -----------------------------------------------------------  Resource: com/fulcrologic/fulcro/routing/legacy_ui_routers.cljc:2:1  constant React assigned a value more than once. Original definition at externs.shadow.js:4 --------------------------------------------------------------------------------


so, @kevin842, technically shadow-cljs makes it so we can alias React out of the non-global space, but for legacy reasons some ppl might still use cljsjs, so if I write Fulcro to only assume shadow, it may fail for some users that only use cljsjs if I don’t rely on a global sym…but shadow won’t add that global sym. I also don’t know what order things will load in…so, kind of a mess. If anything, at this point, I should probably assume people have outgrown cljsjs and just make a release that cuts and runs from it, but then I have to test to make sure what I do works with both standard cljs compiler and the shadow-cljs build tool…which is a lot of testing I don’t have time for. If you are interested in putting together a version of the template that uses non-shadow tooling so both tool chains can be tested, then I’d love to publish that alongside the current template (could even just be an alt branch) and ditch the ugliness


so, those lines are me currently being paranoid since I have not tested the “std” tool chain


and there could be ordering issues that result from such side-effecting garbage…it needs a good cleaning, I just don’t have the time. I will welcome a PR for a template branch with non-shadow compile and a companion PR that cleans this up, but otherwise it can just sit for nwo


really, I was halfway through ditching cljsjs, and I realized I could possibly be breaking things…and I don’t want to even imply that I’ve left anything very sane sitting around…no one has complained, till now 😜


since this warning only appears if I load legacy￱￱ui￱￱routers.cljc, if the line in question is necessary for avoiding breakage in other toolchains, then it's already the case that most of fulcro3 is incompatible with them right?


I’ve peppered that line about in a couple of places


huh, ripgrep only shows me one line for set.￱*￱js/React. in any case thanks for the context, I'll leave it be for now -- still getting to know fulcro. Lots of fun so far :)


hm…perhaps I changed my mind at some pt and forgot to remove that one…entirely possible


too many things 😄


that rings some kind of bell, actually


@tony.kay FWIW unless you want to support old versions of CLJS and CLJSJS you can do (:require ["react" :as react]) without the global just fine nowadays even outside shadow-cljs

👍 1

cljsjs/react has provided the necessary :foreign-libs stuff to expose that name for a while now and moving away from the js/React global will make things much easier to people using the :target :bundle from CLJS


but yeah would probably still require some kind of test suite 😛


I'm currently testing for fulcro-rad-datomic, with the fulcro-rad-demo but it throws an exception :db.error/unsupported-protocol Unsupported protocol :dev And I assume, that's because the code uses the peer-api and not the client-api. Could that be correct? (I know this is more than bleeding edge right now, sorry)


Thanks for testing… @U016TR1B18E will have to chime in on that

Tyler Nisonoff19:08:38

Yes, the demo is written for on-prem, so you need to replace requires of the form [datomic.api :as d] to [datomic.client.api :as d] I can try to throw together a demo fork that uses the PR this week — its pretty simple beyond that. The other change I can think of off the top of my head is in src/config/defaults.edn I set something like this:

                                    {:main {:datomic/schema :production
                                            :datomic/database "example"
                                            :datomic/client {:server-type :dev-local
                                                             :system "dev"}
                                            :datomic/prevent-changes? true}}

Tyler Nisonoff19:08:40

@U012ADU90SW happy to answer any questions of issues you run into — threading here is probably best so others can see them if they try it out soon. I’m hoping to touch up the PR tonight / tomorrow


Thanks guys I really appreciate your efforts! I monkey patched the require statement some hours ago, but probably messed something up, because I got another error. I'll try a fresh checkout from source for everything and give it another shot later. Here's my config btw. I just tried to throw a quick test together based on the official datomic dev-local setup:

                                    {:main {:datomic/schema           :production
                                            :datomic/driver           :dev
                                            :datomic/database         "example"
                                            :dev/host "localhost"
                                            :dev/port 4334
                                            :datomic/access-key       "myaccesskey"
                                            :datomic/secret           "mysecret"
                                            :datomic/prevent-changes? false}}

Tyler Nisonoff20:08:21

oh the queries in database_queries.clj use on-prem only syntax — I had to re-write the queries slightly to work for cloud

Tyler Nisonoff20:08:45

I should throw up a version of the demo that works with the PR — can try to get to that later tonight / tomorrow

Tyler Nisonoff20:08:26

/ maybe I’ll submit a change to the demo that uses the client query syntax (that on-prem also supports)

👍 2
Tyler Nisonoff02:08:58

ugh, the peer and client APIs are too different to unify the queries… the return types from d/q are different 😞


yeah, I spent the night replacing peer with client API calls but as you found out too - that's a pretty bad idea 🙃 I had another demo project (luminus based though) lying around. Turns out you can leave the peer-api as-is but you need to change the dependency from datomic-free to datomic-pro . This way I got my dev-local setup to work on that luminus demo


There is middle ground in the APIs…you could just rewrite the functions so they work right in both? Or are you saying that would just add in weird conditionals?

Tyler Nisonoff16:08:22

It would add weird conditionals — I’m sure I can do it, was just making the code a little gnarly i can write some helpers and use those and get something working, just wasn’t sure if you’d want that complexity in the demo, or if it’d be worth just maintaining a separate rad cloud reference repo somewhere (I could host a fork and we could point to it from the README, for example) I can take another stab


I don’t use client API, but my impression was that it just “had less”: subset of main API: no entity API, more limited q, and no pull-many.


In that case, why not rewrite the functions to “do the right thing” with the subset API that works the same in both. That would make the demo minimally complex, since otherwise we’d have to add yet another source path alias to swap out files.

Tyler Nisonoff17:08:19

thats what i thought as well, but using the same API subset, i get different return formats, so its not that simple 😞


well, given that you have to have two diff requires, I guess we already needed source magic

Tyler Nisonoff17:08:25

yeah, so i think there are three options: 1. Write some helpers / add some complexity to database_queries so that you just swap in the right require in the demo and it works 2. Do nothing, someone else sets up an example demo 3. set up a datomic_cloud directory and alias, which duplicates database_queries, but automatically works for cloud


4. Make a branch where the datomic code is for cloud

Tyler Nisonoff18:08:07

happy to do whichever you prefer -- want me to start with (4)?

Tyler Nisonoff01:08:38

PR here: I need a cloud branch set up in the main repo I can merge this into — then we’re good to go


branch created and pushed


on testing: I just need to know that using the new rad datomic adapter with the demo in SQL mode works, and using it in regular Datomic mode works…i.e. pre-existing behavior is not broken.


of course, it is also good if the cloud stuff works 😄


also is there a doc update in readme? @U016TR1B18E

Tyler Nisonoff16:08:35

I’ll update the REAME Regular Datomic works if we add the dev local package to the demo, will get that PR out too I forgot to test SQL, but can do that too


Thanks for your work guys! I'm going to test the datomic-cloud PR now and I can also try SQL with a local postgres db later


Oh I forgot to mention this, I'm testing the PR with a datomic dev-local setup