Fork me on GitHub
#fulcro
<
2020-10-05
>
Akiyama09:10:41

hey there, is there another way to add no-value attributes (like disabled) to HTML tags aside from (dom/div {:disabled ""} ...)? I combed through the book and this seems to be the only way to do so, but honestly it looks kinda… weird so is there a more elegant way to do it?

Björn Ebbinghaus11:10:07

Use: {:disabled true}

Akiyama03:10:14

It's working now. Thanks.

exit216:10:08

This might be more of a pathom question, but is the typical way of setting up a resolver where you might not know all the outputs from the api response something like:

tvaughan18:10:59

Our resolver returns :stuff (not the actual name) which is a hash-map of all the stuff we're not sure will be returned and which we have little control over (just enough control to coerce everything under the stuff keyword)

exit216:10:15

(pc/defresolver some-resolver
                [__ {:keys [resource/id]}]
                {::pc/input #{:resource/id}
                 ::pc/output [:id]}
                (let [resource (get-resource-by-id id)]
                  resource))

exit216:10:36

where I could still query other parts of the response like: [{[:resource/id 1] [:id :name]}]

exit216:10:45

but I wouldn’t get the auto-complete in the fulcro inspect

currentoor16:10:30

@njustice definitely a pathom question, they have a separate channel simple_smile

currentoor16:10:01

anyway, no, the output needs to include :name

currentoor16:10:14

if you want to be able to query for :name

exit216:10:06

hmm.. odd with what I have above I query any keyword in the response of resource

exit216:10:31

my example query works, and returns {[:resource/id 1] {:name "foo", :id 1}}

exit216:10:43

(at least it works in fc inspect query)

currentoor16:10:52

hmm, might be a feature of a newer version? or i'm misremembering

exit216:10:19

it would be tricky for me to know all the properties the api will respond with, I.e. a new field is added to the response

exit216:10:07

I recalled Tony saying something (in the videos) about how ::pc/output helps w/ auto-complete but you can query other fields - but I could also be misremembering

tony.kay21:10:57

output is used to build indexes in Pathom, so autocomplete won’t work without that info. You can return stuff from a resolver that isn’t advertised, but treat that as an optimization since pathom itself would not know to ask for it from that source. For example, say you have a resolver for fact A that can be retrieved via some ID, but another route can also give A if it is hit. If that route does not advertise it can return A then it will never be asked for A; however, if it is hit first and provides A anyway, then Pathom will detect that is already has A and won’t go looking to resolve it if it then finds that it needs it.

currentoor16:10:55

totally could be correct 😅

exit216:10:32

haha let me see if I can find the part in the videos 😄

zilti20:10:32

Hmm, did something change/break with Fulcro and/or the Inspect tool? The tool loads an initial state, but then is "stuck" on it. Even a tab refresh doesn't un-stuck it. Meanwhile, I get about two dozen copies of this error in the console:

zilti20:10:32

Hmm, did something change/break with Fulcro and/or the Inspect tool? The tool loads an initial state, but then is "stuck" on it. Even a tab refresh doesn't un-stuck it. Meanwhile, I get about two dozen copies of this error in the console:

holyjak20:10:50

Do you get the warnings logged also in a browser without Inspect, eg Firefox?

zilti20:10:21

Good point. I just checked, and yes I do. Although only four times.

tony.kay21:10:34

@U2APCNHCN versions?

tony.kay21:10:48

Latest Fulcro requires manual update to inspect at the moment

tony.kay21:10:54

I’ve been messaging about it all week

zilti21:10:31

3.4.1 currently. Ah, I'll try that then!

tony.kay21:10:16

yes, 3.4.1 will NOT work with the Chrome store version of Inspect

zilti21:10:22

Hmm it still doesn't work though. Same errors in console, same behaviour

tony.kay21:10:49

I would recommend using the latest Inspect (which requires 3.4.3-SNAPSHOT of Fulcro). They depend on each other.

tony.kay21:10:52

it definitely works for me, so you’ll have to provide much more context if you want further help: OS Versions involved Errors from your console Errors from Inspect’s console (right click on Fulcro Inspect and choose Inspect)

tony.kay21:10:03

screen shot of UI of Inspect

zilti21:10:29

Well, since I also get the same errors in Firefox without Inspect, I am not even sure if Inspect is the cause

zilti21:10:01

Okay, latest Inspect, Fulcro 3.4.3-SNAPSHOT. Console errors: see screenshot above. Errors from Inspect's console: none.

tony.kay21:10:18

the console errors you’re showing me have to do with your routing and application startup mistakes (they are harmless, though), nothing to do with inspect.

tony.kay21:10:58

all that’s happening there is you’re rendering routers before you’ve started them.

tony.kay21:10:39

(which is harmless, but deserves a warning because that could be a problem in non-startup scenarios)

tony.kay21:10:40

I’d recommend quitting/restarting Chrome. You must at least start a new tab to get a newly installed inspect.

tony.kay21:10:50

and make sure you uninstalled the old one

zilti21:10:43

Hmm, quitting/restarting Chrome helped. Also, good to know where the warnings are from (a bit odd though that they get repeated so many times). As always, thank you a lot!

tony.kay23:10:38

sure. In terms of repeating: yeah, they will repeat on every render until the SM starts, so that really depends on how many animation frames you cause before a route gets triggered to start the SM. You can use app/set-root! with initialize state, then dr/initialize! or dr/change-route!, then app/mount! with NO initialize state to get rid of most or all of those. Basically: Make sure you’ve explicitly routed to a leaf (target) before mounting.

tony.kay23:10:00

(initialize just makes sure all routers have started their state machiens)

exit220:10:18

When developing locally for a full stack application, how do we tell the client the location of the server? POST 404 (Not Found)

exit220:10:55

Are we not to develop from 8000 and have it hit 3000/api?

exit220:10:55

Are we not to develop from 8000 and have it hit 3000/api?

exit221:10:25

Ok, so deving from 3000 make sense. But why do I get this error when trying to go to a page that fetches data from the API?

exit221:10:46

core.cljs:159 WARN [com.fulcrologic.fulcro.networking.http-remote:184] - Transit decode failed!

exit221:10:52

core.cljs:159 ERROR [com.fulcrologic.fulcro.networking.http-remote:344] - 
#error {:message "Remote Error"

exit221:10:23

strangely enough, I can go to the server localhost:3000/index.html and navigate to that page via a link and the page loads, data renders..

tony.kay21:10:57

I’ll restate it in case anyone missed it: The current Chrome Store release of Inspect will not work with Fulcro 3.4+. There are pre-release versions of the new Inspect that you can manually install here: https://github.com/fulcrologic/fulcro-inspect/releases

tony.kay21:10:07

both Chrome and Electron