This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-15
Channels
- # announcements (2)
- # babashka (41)
- # beginners (10)
- # calva (62)
- # chlorine-clover (70)
- # cider (19)
- # clara (2)
- # clj-http (1)
- # clj-kondo (1)
- # cljs-dev (3)
- # cljsrn (8)
- # clojure (168)
- # clojure-austin (1)
- # clojure-australia (2)
- # clojure-canada (1)
- # clojure-europe (15)
- # clojure-france (9)
- # clojure-nl (3)
- # clojure-serbia (5)
- # clojure-spec (14)
- # clojure-uk (8)
- # clojurescript (14)
- # community-development (30)
- # core-async (42)
- # core-typed (1)
- # datahike (2)
- # datalog (23)
- # datomic (4)
- # emacs (4)
- # figwheel-main (4)
- # fulcro (67)
- # ghostwheel (4)
- # girouette (1)
- # gorilla (7)
- # graalvm (11)
- # heroku (8)
- # integrant (42)
- # jobs (6)
- # jobs-discuss (47)
- # kaocha (7)
- # lambdaisland (2)
- # leiningen (5)
- # lsp (29)
- # off-topic (1)
- # pathom (9)
- # portal (6)
- # re-frame (5)
- # reagent (11)
- # releases (6)
- # remote-jobs (10)
- # shadow-cljs (112)
- # testing (55)
- # vrac (1)
In RAD, I'd like to have a report with checkbox controls to show/hide some columns but I see no simple way of doing that, other than creating my own table and row components. Correct?
no PR required. RAD is designed to allow you to take over rendering and do whatever you want. If you wanted that particular behavior over and over, then you’d write a rendering plugin (like the semantic UI one, or extend the SUI one) and add those features to your UI plugin. The core RAD stuff would need no modifications if you just follow the existing patterns. The only pain I see is that you’d have to have a place in the component query for the data you’d want to hold onto (which columns are hidden). You could do that with hooks in the custom rendering, of course, but it might be nice to at least persist that to app state, and therefore you’d need a query inclusion on the top-level report.
Thanks Tony, So for me the use case is to hide show/hide based on report controls and/or viewport width (ex: only display this field on desktop) I understand I can write my own ui code in the defsc-report but I would rather have it as a ro/show-columns option to use the auto gen render.
@U03K8V573EC might have some tips here Personally, I just copy the relevant parts of the plugin to my project, modify, and change sui-controls to point to the modified copy. See e.g. here https://github.com/holyjak/fulcro-billing-app/blob/main/src/shared/billing_app/ui_utils/rad_controls.cljc#L23
I copy namespaces and tune them, refer to my copy in controls map.
I’m busy trying to track down a bug in my app and just want to check that what I’m trying to do is supported. I have a union component that has a to many recursive collection of itself. The union component uses the correct query when in isolation but when the union component is a child it doesn’t use the correct query when its type differs from its parent. It’s denormalised using the parent’s type query.
This is a minimal failing test https://github.com/fulcrologic/fulcro/pull/473/files Is this supposed to work in theory?
I see it’s actually deeper than that… reading the EQL docs it doesn’t seem to me, on first reading at least, that the semantics of recursive unions are spelt out explicitly… but how the AST is structured it seems to me that implicitly a recursive union was intended to only be of one type
…no, I think there isn’t an implied semantics in the AST. I think it might be in fulcro…
So I’ve written an ultra hacky hack that detects if the node we’re trying to normalise is a recursive union and uses the ‘correct’ query for the join-entity. It amounts to an extra cond branch in add-join!
. With a little work it will probably just be a modification of the (and recursive? join-entity)
branch.
At first blush it might need an extra field in the EQL AST to keep the whole union in the children node but that would at most be just an extra key in :union-entry
nodes if it’s truly needed.
What’s not entirely clear to me though is what are the expected semantics of recursive union components and queries… is it up to Fulcro to decide? Is this worth pursuing, I’d be happy to keep going at the PR if there is a chance this will be used.
Granted I haven’t thought too hard about the downsides, I do think this is really useful and I would like to make a case that it is the natural expression of recursive union components.
It has been a very long time since I looked at recursion in the context of unions (which I almost never use). I’m not sure if I ever planned to support the specific use-case you’re trying (honestly have no memory…4-5 yrs ago). We have pretty solid tests for db->tree, so you’re welcome to take a shot at implementing it.
I am trying to use JS async/await
functions from 3rd party libraries in Fulcro. I have tried using mutations and state machine to handle the asynchrony of the call, but without success. Does anyone have any experience solving this problem? I appreciate what you can share.
Async just returns a promise, no? Cannot you simply (.then promise #(transact this-component...))?
The problem is that I am integrating an image picker with a UI component. So I am trying to pick an image then display it. The image picker is async.
What exactly does it do? Pick an image from the disk, upload, display? Or pick an image from a list of images? What do you get from the picker, an url?
I can't put a Promise or a go block inside a render code block. I can't put it in the event handler of a state machine either.
I assume the picker is a React component that you nest in your fulcro component and that it expects that you pass it a callback it will call when the user has picked. Or?
I don't seem to have a callback. The React example uses await
I am sure I can convert that to a callback though.
No @U0522TWDA. I did not solve it. Here is my code:
(defsc Photo [this {:ui/keys [photo] :as props}]
{:ident (fn [] [:component/id ::Photo])
:query (fn [] [:ui/photo])
:initial-state (fn [photo] {:ui/photo photo})
:route-segment ["photo"]}
(log/debug "Photo props" props)
(let [foo (-> (.requestMediaLibraryPermissionsAsync ImagePicker)
(.then (fn [resp]
(let [granted? ^boolean (.-granted resp)]
(if granted?
(-> (.launchImageLibraryAsync ImagePicker)
(.then (fn [resp]
(let [cancelled? ^boolean (.-cancelled resp)
photo (.-uri resp)]
(when-not cancelled?
(log/debug "Photo uri=" photo)
(n/ui-view {:style {:flex 1}}
(n/ui-text {} "Hello there!!!!!!")
(n/ui-image
{:source {:uri photo}})
(rne/ui-button {:title "Accept"
:buttonStyle {:height 40}
:onPress (fn [] (js/alert "You pressed the button!"))}))))))))))))]))
The code inside the .then
does not render.Can you not separate out the ui and promise handling code? You might need some internal state to orchestrate? I don’t think what you’re trying to do will ever work the way you want it to.
The Photo component’s render method (the body of the macro) needs to return react dom constructors. You’re not even using foo
in the body
Hi @U0VP19K6K. I have tried to separate the ui and promise code. I tried a transaction, and a statemachine without success. I don't use foo, because it is an object and React was complaining about it. I am stumped as to how to separate the concerns.
The problem is that the function returns immediately, then computes the result and saves it. I don't know how to deref a promise.
Sorry @UGNMGFJG3 I have food about to arrive but…
and in the .then callback update that state with whatever is in resp
(it looks like it’s a URL)
if you do, do whatver you want like displaying the image, if not show a button saying ‘upload the image’
You may want to find a plain React tutorial on how to build an upload button… that might help you understand what you need to do?
Thanks @U0VP19K6K
As donovan says. Put the body into photo and inside the then just store the url so the photo component can see it, either in local state or in the Fulcro client db: do there something like (transact! this [(m/set-string :ui/img-url <the url>]))
Thanks @U0522TWDA. How do I know when the uri is ready?
I'd do this
(defsc Photo [this {:ui/keys [photo] :as props}]
{:ident (fn [] [:component/id ::Photo])
:query [:ui/photo]
:initial-state {:ui/photo :params/photo}
:route-segment ["photo"]}
(log/debug "Photo props" props)
(if photo
(n/ui-view {:style {:flex 1}}
(n/ui-text {} "Hello there!!!!!!")
(n/ui-image {:source {:uri photo}})
(rne/ui-button {:title "Accept"
:buttonStyle {:height 40}
:onPress (fn [] (js/alert "You pressed the button!"))}))
(do
(-> (.requestMediaLibraryPermissionsAsync ImagePicker)
(.then (fn [resp]
(when (.-granted resp)
(.launchImageLibraryAsync ImagePicker))))
(.then (fn [resp]
(when (and resp (not (.-cancelled resp)))
(m/set-string! this :ui/photo (.-uri resp))))))
(dom/p "..."))))
This is a minimal failing test https://github.com/fulcrologic/fulcro/pull/473/files Is this supposed to work in theory?
Hi all, I remember seeing a message here about using Fulcro via a React hook. Does anyone know where that’s documented? Thanks
What do you need? Use hook based instead of class based components? See the doc string of defsc and the Dev Guide
Using Fulcro without Fulcro components, via hooks, see the develop branch and the raw-components namespace
Search the code for its usages to find the examples.
Thanks @U0522TWDA! I was thinking the second. Using Fulcro without Fulcro components
It was something with raw and components, not sure about the order :)
See the composition cards in the fulcro-3.5 branch ( in progress). Those will be the more ideal items.
So I’ve written an ultra hacky hack that detects if the node we’re trying to normalise is a recursive union and uses the ‘correct’ query for the join-entity. It amounts to an extra cond branch in add-join!
. With a little work it will probably just be a modification of the (and recursive? join-entity)
branch.
At first blush it might need an extra field in the EQL AST to keep the whole union in the children node but that would at most be just an extra key in :union-entry
nodes if it’s truly needed.
What’s not entirely clear to me though is what are the expected semantics of recursive union components and queries… is it up to Fulcro to decide? Is this worth pursuing, I’d be happy to keep going at the PR if there is a chance this will be used.
Granted I haven’t thought too hard about the downsides, I do think this is really useful and I would like to make a case that it is the natural expression of recursive union components.
I’m attempting to use ao/style :autocomplete
with a RAD :string
attribute, but I’m getting an error thrown Uncaught Error: Assert failed: (or (eql/ident? server-property-or-ident) (keyword? server-property-or-ident))
because the :autocomplete/search-key
is nil
in com.fulcrologic.rad.rendering.semantic-ui.autocomplete/AutocompleteField :initLocalState
I’m setting that key in the form like:
fo/field-options {:worktime/task {:autocomplete/search-key :worktime/tasks}}
but it’s missing in the initLocalState call. I think I’m making progress on figuring this out, but maybe there’s a known problem.I made a change that fixes the error above, so the remote call is happening, and the options are getting stored, but they’re still not showing up back in the dropdown in the browser. https://github.com/thosmos/fulcro-rad-semantic-ui/tree/bugfix/autocomplete
Is the autocomplete used in the demo? I thought I used everything that was supported in the demo. Perhaps you are using the options incorrectly. I don’t remember off the top of my head, which is why I tried to use everything in the demo…could be I overlooked that one, but I know I’ve used autocomplete at some point.
It looks like the only :autocomplete
in the demo is for an :enum
type, not a :string
type, and it looks like it only supports having the fo/field-options
on the attribute, and not on the form itself. I’ll just use it as a starting point and make my own.
Putting the options on the attribute with fo/field-options
eliminates the PR I made (I thought that field-options was only for forms), but the dropdown options are still not rendering into the UI, even though they’re where they should be at [::autocomplete-id id :ui/options]
in the app DB. It appears that when AutocompleteFieldRoot
renders, :ui/options
is missing, so when it passes that as props to AutocompleteField
, it never sees the :ui/options
The problem seems to be here:
field (get-in props [::autocomplete-id id])
which is null and gets passed to the instance like
(ui-autocomplete-field (assoc field
::autocomplete-id id
:autocomplete/search-key search-key
:autocomplete/debounce-ms debounce-ms)
oooh, does this have something to do with which rendering strategy I’m using? :optimized-render! kf2/render!
Even though it’s working now, it brings up that I think there’s some confusing different places where field-options are located. for example, here’s the let
from po/load-options!
[{:com.fulcrologic.rad.form/keys [field-options]} (comp/component-options form-class)
field-options (get field-options qualified-key)
picker-options (merge attribute field-options)]
It merges field-options
from the form directly into the attribute’s map, rather than into ::form/field-options
consistent with what my PR change did.
In other words, I think the way the :autocomplete
is coded in the demo is inconsistent, and the implementation of the :autocomplete
component should be changed (breaking) to get its :autocomplete/keys
from either ::form/field-options
on a form, or directly from the attribute map, which is consistent with everywhere else.I don’t think there is a need to break it…just add the corrected locations as possibilities via or
, where form overrides attribute, and the old location has the least precedence (or form-value correct-attr-location old-attr-location)