Fork me on GitHub
#fulcro
<
2019-06-22
>
levitanong08:06:35

@tony.kay that looks great! That’s a huge quality of life improvement

cjsauer16:06:46

Hello all 👋 How would one adapt a HOC like createStackNavigator to Fulcro? https://reactnavigation.org/docs/en/hello-react-navigation.html I’m having a hard time figuring out how exactly to wrap my HomeScreen component…

cjsauer18:06:05

Still having a bit of trouble with this…I’m generally confused by how to handle a third-party JS library being in control of mounting my Fulcro components. I’m suddenly no longer in control of what props are passed, and I’ve noticed that the “Fulcro context” has also been dropped (reconciler, etc). How would one thread this context thru the third-party component, and when/if that’s achieved, where are those child Fulcro components located in the tree, i.e. where are their queries rooted?

eoliphant16:06:54

@cjsauer There’s a bit of code here (and a bit more discussion before that): http://book.fulcrologic.com/#_reusable_hoc_factory

cjsauer17:06:03

@eoliphant thanks, I’ve been referencing that. Came up with this:

(defn router-hoc-factory
  ([hoc-wrapper-fn router-config nav-config]
   (hoc-factory hoc-wrapper-fn router-config nav-config nil))
  ([hoc-wrapper-fn router-config nav-config {:keys [extra-props-fn]}]
   (let [cljs-props-key (name (gensym "fulcro-cljs-props"))
         adapt-screen-class
         (fn [config [screen-key screen-class]]
           (let [screen-factory (prim/factory screen-class)
                 adapted-class  (fn [js-props]
                                  (let [clj-props (goog.object/get js-props cljs-props-key)
                                        props     (if extra-props-fn
                                                    (extra-props-fn js-props clj-props)
                                                    clj-props)]
                                    (screen-factory props)))]
             (assoc config screen-key adapted-class)))
         adapted-router-config (reduce adapt-screen-class {} router-config)
         hoc-component-class   (hoc-wrapper-fn (clj->js adapted-router-config)
                                               (clj->js nav-config))]
     (fn [props & children]
       (apply r/createElement
              hoc-component-class
              (js-obj cljs-props-key props)
              children)))))

(defn create-stack-router
  [route-config nav-config]
  (router-hoc-factory (comp createAppContainer createStackNavigator)
                      route-config
                      nav-config
                      {:extra-props-fn (fn [js-props clj-props]
                                         (assoc clj-props :navigation (gobj/get js-props "navigation")))}))

eoliphant17:06:24

is that working for you?

cjsauer17:06:01

Appears to be…only thing I need to do is assoc in the route params as well….

cjsauer17:06:07

I think then I can create entities for screens, like [:screen/by-id :home], and “switch” on that based on route parameters

cjsauer17:06:26

:extra-props-fn seems like a good place to slot that in

eoliphant17:06:23

sweet. personally I wish HOCs would go away lol. the “Infectious Decorator” pattern is what I like to call it

cjsauer17:06:48

Yeah, they sure do cause a good amount of boilerplate on the clj side of the fence…

eoliphant17:06:41

yeah and even in pure JS, I’ve never been a fan. The whole point of a decorator is that the decorated thing doesn’t depend on it. Now that hooks are out, I’m seeing at lot of libs provide alternatives via that route

cjsauer17:06:43

Haven’t seen hooks before, they look interesting tho

eoliphant17:06:43

yeah they’re actually way more ‘functional’

uwo18:06:24

I'd like to issue a query like this to a remote with a Pathom resolver,

[{[:carrier/id <some-carrier-id>]
    [:freight-bill/modes-by-carrier]}]
However, I don't want the query results to be normalized because I want to specify the target. I know it's possible to issue the above query by providing an ident when calling load, but that ignores target and normalizes the response in the client-db. I know how to rephrase this query to use :params in env, but I'd prefer to use an explicit input for the resolver in this case.

cjsauer18:06:05

Still having a bit of trouble with this…I’m generally confused by how to handle a third-party JS library being in control of mounting my Fulcro components. I’m suddenly no longer in control of what props are passed, and I’ve noticed that the “Fulcro context” has also been dropped (reconciler, etc). How would one thread this context thru the third-party component, and when/if that’s achieved, where are those child Fulcro components located in the tree, i.e. where are their queries rooted?