This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-05
Channels
- # beginners (229)
- # cider (54)
- # cljs-dev (187)
- # cljsrn (1)
- # clojure (187)
- # clojure-dev (5)
- # clojure-italy (31)
- # clojure-losangeles (1)
- # clojure-russia (3)
- # clojure-spec (76)
- # clojure-uk (29)
- # clojurescript (94)
- # cursive (18)
- # datascript (8)
- # datomic (26)
- # docker (6)
- # emacs (19)
- # figwheel (6)
- # fulcro (41)
- # garden (1)
- # graphql (1)
- # hoplon (33)
- # jobs (1)
- # jobs-discuss (1)
- # lein-figwheel (14)
- # leiningen (7)
- # nrepl (10)
- # nyc (1)
- # off-topic (2)
- # onyx (2)
- # parinfer (25)
- # portkey (6)
- # powderkeg (1)
- # protorepl (1)
- # re-frame (14)
- # reagent (14)
- # shadow-cljs (31)
- # spacemacs (3)
- # test-check (33)
- # uncomplicate (1)
- # unrepl (40)
- # vim (5)
- # yada (16)
@wilkerlucio placeholder plugin is a read wrapper whose position in the plugin chain is after walkable, so I guess I should just assoc ::p/placeholder-prefixes
or something to env from the beginning. Otherwise we need two parts of such placeholder plugins, one for read, the other for manipulating the env
I guess we should update placeholder plugin to something like this:
(defn placeholder-reader
"Produces a reader that will respond to any keyword whose namespace
is in the set `(::placeholder-prefixes env)`. The join node logical
level stays the same as the parent where the placeholder node is
requested."
(fn [{::keys [placeholder-prefixes] :as env}]
(if (contains? placeholder-prefixes (namespace (:dispatch-key ast)))
(join env)
::continue)))
I agree this implementation is better, but this would be a breaking change, and breaking changes are not good... so my suggestion is to deprecate the current placeholder-reader
but keep it as is, and I can add a new env-placeholder-reader
(name subject to change, suggestions are welcome), then you can suggest your users to use the new one, and we don't break the current usages
I agree. I'll make a PR later today
@jzhu5121 That is true, you will see that warning because in that video we have yet to add queries. As a result transactions result in a root level refresh, which is less efficient that a localized UI refresh…but a localized refresh cannot happen unless there are queries and idents on the component. In the video series I’m trying to build things up one at a time 🙂
So, no point in mentioning the missing queries and idents yet, since you don’t even know what they are at that early stage 😉
Hello, a quick question - I tried to search through the docstrings and in the book but can’t find it: does defcard-fulcro
run normalization of the supplied initial state map? I guess it’s not - if that’s the case how can I get the normalization applied to my initial state map?
(defcard-fulcro ContactList
ContactList
(prim/get-initial-state
ContactList
{:id 1000
:contacts [{:id 1 :name "Bob" :email ""}
{:id 2 :name "Alice" :email "alice@examplecom"}]})
{:inspect-data true})
And question 2: I have the following example component:
(defsc ContactForm [this {:keys [:db/id :contact/name :contact/email]}]
{:ident [:db/id :db/id]
:query [:db/id :contact/name :contact/email]
:initial-state {:db/id :param/id
:contact/name :param/name
:contact/email :param/email}}
(dom/div nil
(dom/input #js {:value name :onChange (partial m/set-string! this :contact/name :event)})))
and I play with it in the following devcard:
(defcard-fulcro ContactForm
ContactForm
(prim/get-initial-state
ContactForm
{:id 1
:name "Alice"
:email ""})
{:inspect-data true})
but the mutation fails with:
> Mutation fulcro.client.mutations/set-props failed with exception Error: No protocol method IAssociative.-assoc defined for type number: 1
I guess it is caused by lack of the normalization applied to my card initial state map but I would like to confirm that’s the caseSo, if you put initial state on the component, then it will find them and normalize it. If you supply the initial state through the card, then it has to be a pre-normalized database
The issue is that my initial state is parametrised and I am not sure it’s possible to pass params that should be used by the fulcro card to call get-initial-state on the root compoennt
but also realize that a component with an ident isn’t quite right for a root, either
it’s a function you can pass your component to, and it’ll wrap it in a boilerplate root
You have to use the prim/ui
tool instead of defsc/defui…and you no longer need react-key…but that would save you the typing
I imagine you could close over params from outside of initial state and get what you’re looking for
And if I got with just defining the root manually instead of the util fn, should I got with defsc or defui?
For an easy-server, is the :handler object stored in the system component the ring handler - or is it [:handler :middleware]? Planning to test deploying to aws elasticbeanstalk with lein-elastic-beanstalk - unless anyone has other suggestion (want to access datomic cloud).
Thanks @tony.kay, I think a small root with sample data is simpler:
(defsc ContactListRoot [this {:keys [:root/contact-list]}]
{:query [{:root/contact-list (prim/get-query ContactList)}]
:initial-state (fn [_params]
{:root/contact-list
(prim/get-initial-state
ContactList
{:id 1000
:contacts [{:id 1 :name "Bob" :email ""}
{:id 2 :name "Alice" :email "alice@examplecom"}]})})}
(ui-contact-list contact-list))
(defcard-fulcro ContactList
ContactListRoot
{}
{:inspect-data true})
@piotrek I added make-root
to fulcro.client-cards and pushed it in 2.3.1-SNAPSHOT. I meets this need, and I’d be glad to expand it for other devcard convenience. It does come up a decent amount.