Fork me on GitHub
#fulcro
<
2020-12-28
>
AJ Snow03:12:39

@tony you suggested the possibility of a scroll trigger a while ago. from what I'm seeing, it looks like I'd need to create a usim/trigger event of some kind for this. Is that right, or are there other available approaches? I guess maybe I could attach it to a div. would that be :onScroll ?

ej13:12:25

Is defsc short for define stateful component?

👍 6
wilkerlucio13:12:36

which is unfortunate, given you can also use it for stateless components, but will not change for compatibility

Björn Ebbinghaus13:12:40

> The name means “define stateful component” and is intended to be used with components that have queries (though that is not a requirement). https://book.fulcrologic.com/#_the_defsc_macro

tony.kay01:12:45

Right, it is a little bit of a misnomer, but it is really hard to come up with good names. The vast majority of components you write in Fulcro will have queries, and therefore state in the database. Technically pre-hooks such components always have access to component-local state, so you can say that the name is actually completely accurate for the time period in which it was named. If you don’t need any kind of state, then what you want is a function. However, now that hooks are here it is possible you might want to define a component that is just a function (presumably for side effects), and while there is usually some kind of state involved it is technically possible to make a thing that has no concept of state…but using defsc for hooks also implies that you are going to use a query for that case…otherwise why not just write a function?

wilkerlucio11:12:46

I personally use a lot of defsc to define UI root components, they usually dont have any query but I want defsc to use the fulcro css system

tony.kay15:12:35

@U066U8JQJ do you even mount those, or just use them for a place to put namespaced CSS?

wilkerlucio15:12:30

yes, I mount them, they are usually the design system part of the application, buttons, checkboxes...

tony.kay16:12:32

oh, you don’t mean “root” components. I think you mean “stateless leaf” components 😉

tony.kay16:12:01

root to me means something you pass to mount

wilkerlucio16:12:57

sorry, bad naming on my part

wilkerlucio16:12:03

yeah, not root

JAtkins19:12:07

React HOC components in theory work fine with fulcro I think. (defsc wrapping defsc). Is there any reason to not write code this way, and if so what is the alternative that still allows me to decorate components with additional functionality?

JAtkins19:12:56

Perhaps use defsc* to generate components dynamically that merge the queries and initial state of the wrapped and wrapper classes?

Jakub Holý (HolyJak)20:12:23

I haven't so far had a need for a HoC but I've only built two applications...

JAtkins20:12:19

I'm trying to make a generalized "highlight on hover and tell X that you are hovered" pattern... Maybe it's just a fn wrapper? I know there are several ways to hack it together, just not sure of the best way to hack it together 🙂

JAtkins20:12:39

Pure stateless fn wrapper

(fn wrap-highlight [factory* notify-fn*]
  (fn wrap-highlight* [props]
    (dom/div {:onMouseOver #(notify-fn* ...)}
      (factory* props))))

JAtkins20:12:02

But that feels wrong

dvingo20:12:25

wrapping defsc is a good idea, Wilker talks about it here: https://www.youtube.com/watch?v=R_XPwi0Kiwk

👀 3
❤️ 3
JAtkins20:12:09

Related question: is it sane to have another component render your children?

(defsc WrapperWhatever [this {:keys [:component/id] :as props} {:keys [child-props child-factory]}]
  {:query [:component/id :component/local-state]
   :ident :component/id}
  (dom/div #_"whatever mess you want in your wrapper"
    (child-factory child-props)))

(def ui-wrapper-whatever (comp/computed-factory WrapperWhatever {:keyfn :component/id}))


(defsc ParentThing [this {:keys [:parent/id :parent/child :parent/sub-wrapper] :as props}]
  {:query [:parent/id
           {:parent/child (comp/get-query SomeComponent)}
           {:parent/sub-wrapper (comp/get-query WrapperWhatever)}]
   :initial-state {:parent/child {}
                   :parent/sub-wrapper {}}
   :ident :parent/id}
  (dom/div
    (ui-wrapper-whatever sub-wrapper {:child-props child :child-factory ui-some-component})))

(def ui-parent-thing (comp/factory ParentThing {:keyfn :parent/id}))

JAtkins20:12:28

I guess this is almost the exact same question actually. Just a different approach (dare I say a more sane one?)

Jakub Holý (HolyJak)20:12:41

No time to read the code now but I believe there are examples of this in the book, perhaps using pure JS HoC

JAtkins20:12:54

Yeah, this is about as close as I think I can come to mirroring the regular JS HOC pattern

tony.kay00:12:32

Yes @U5P29DSUS, that’s about the idea. This is a case where the ui tree can vary slightly in shape from the query (them matching exactly is a simplification for new user understanding)

JAtkins00:12:25

Cool, that works.

tony.kay00:12:09

you also have access to comp/children, so you can get the notation of:

(ui-wrapper-whatever sub-wrapper
  (ui-some-component child))

tony.kay00:12:44

non-computed factories send extra things as children