Fork me on GitHub

Hey, did someone know how to usu ::webkit-input-placeholder on css fulcro 2.6?


@veddha.riady I dunno exactly, but you might find something over garden docs, in the end fulcro uses garden to compile the CSS:


so I was under the impression that fulcro did not re-render from root but instead only re-render changed idents. was I wrong or am I doing something wrong?


@thheller it does targeted updates, but how much may vary, I didn't checked closely, but the main idea is that re-render is governed by follow-up reads (or refresh in terms of mutations), so all the components with the same ident will refresh, but also any components that contains the attributes mentioned in the follow up read (and in case of loads fulcro automatically adds some things there)


that said, there were changes that are less optimal than before since 2.6.0, so if you notice some weird root render that could be a bug


@thheller think there is also the rendering modes part. Think the fulcro lein template now has :keyframe added as default.

☝️ 4

Also normally called 'follow on' reads.


If I have a presentational component (for fulcro, one that does not use defsc, ie. does not have a query or ident, purely presentation) I can use a regular function to emit the DOM I need. However, if I need the presentational component to use a callback / computed, do I need to necessarily use a stateful defsc component to pass in the computed?


@pvillegas12 if you are not using query, don't mind computed, just send everything in props


got it, so the computed is for a stateful component for rendering optimization?


regarding my earlier question about rendering from root: I made a small demo repo showing that render always happens from root and I want to find out why or how to optimize it? any feedback/suggestions are welcome


@thheller how can you tell it’s rendering everything from root?


@thheller I’m not sure that the console statement means its re-rendering the root


its the render fn of the component so what else would it mean? (it is absolutely possible that my assumptions are incorrect)


rendering is usually not the most costly operation, computing the data for it is (`db->tree`), I think it's worth the investigation anyway, I myself use a project that can suffer if things are not optimized (quite large app)


yeah I'm not saying that this is a problem


just not what I expected


I'm glad you are bringing it out, this is an important part I didn't had the time to inspect close and see if the opt is working as its supposed to, @tony.kay did some changes on 2.6, in prod I'm not having performance issues, but that doesn't mean it's optimal 🙂


@thheller just curious, why you changed the :root-render in the example?


ah. can take it out. in my UI app I'm not using fulcro.client.dom so the default js/ReactDOM doesn't exist


I have one tip for your mutations


you can instead write:


(defmutation set-name [{:keys [id name] :as params}]
  (action [{:keys [state ref] :as env}]
    (js/console.log ::set-name params)
    (swap! state update-in ref assoc ::name name)


in the tx env you have the ref, which is the ident of the component that triggered the mutation


this way you can always target the correct data point in the app db, making your mutations more generic


then the mutation would be: (db.h/swap-entity! env assoc ::name name)


@thheller interestingly enough, doing :shouldComponentUpdate (fn [_ _] false) on Root will not update the children (the name does not change)


makes sense if its rendering from root


With React, if children’s props change, even if the parent does not update, the children will re-render


the child props can't change if the parent doesn't update because it is passing the props