Fork me on GitHub
#fulcro
<
2018-11-25
>
grzm01:11:48

Doing my x-monthly try-again with Fulcro and devcards. Seeing in a warning devcards.core/dom-node* is not public when calling (defcard-fulcro ,,,)

tony.kay01:11:24

@grzm Not sure. version of devcards? We’ve largely moved from devcards to workspaces (as in the new lein template), but I can’t see why it would stop working unless the latest devcards changed something.

grzm01:11:01

devcards 0.2.6. Yeah, I checked out blame in f.c.cards.cljc and devcards.core thinking something might have changed, but all looks pretty old. Not seeing where dom-node* is referenced in f.c.cards either.

grzm01:11:48

Here’s a repro case, if you’re interested: https://github.com/grzm/figwheel-main-fulcro-devcards

tony.kay04:11:15

@grzm change in clojurescript compiler. If you use the prior version of the compiler it works. CLJS is now warning about private, where it did not before. In order to make that macro work I had to access the bits of devcards that were private.

tony.kay04:11:50

so, the current workaround would be to go back a version. I’ll see if there’s something else in devcards that I can use to make it work…if not, I can just copy the bits out I need.

grzm04:11:55

gotcha. cheers. in the meantime, I’m taking a look at Nubank’s workspaces.

tony.kay04:11:57

Actually, I consider that a bug in devcards…Bruce’s own wrappers for Om Next and such output that same cljs function

tony.kay04:11:12

so, it should not technically be marked private to begin with

tony.kay04:11:46

This is from Devcards itself:

(defmacro om-root
  ([om-comp-fn om-options]
   (when (utils/devcards-active?)
     `(create-idevcard
       (devcards.core/dom-node*
        (fn [data-atom# node#]
          (om.core/root ~om-comp-fn data-atom#
                        (merge ~om-options
                               {:target node#}))))
       {:watch-atom true})))
  ([om-comp-fn]
   (when (utils/devcards-active?)
     `(om-root ~om-comp-fn {}))))

tony.kay04:11:00

that will issue the same warning when used

grzm04:11:34

Is fulcro calling om-root (which in turn is calling dom-node*)?

tony.kay04:11:08

no, I’m just mimicing his other macros

grzm04:11:33

Nope, but dom-node is. And since they’re macros the resulting code look like public calls?

tony.kay04:11:11

perhaps you don’t understand how macros work?

tony.kay04:11:33

no, macros rewrite forms in your file to new forms…as if you wrote them

grzm04:11:42

That’s what I’m trying to say.

tony.kay04:11:54

so, if a macro emits a call to a private function in your ns, then it looks like you ns is trying to hit a private function, yes

grzm04:11:09

Yup. We’re on the same page.

tony.kay04:11:15

cljs didn’t enforce that or even warn about it until this version

tony.kay04:11:38

so it was easy for lib authors to make mistakes that will now cause problems…which is why it is a warning and not a hard error

tony.kay04:11:45

though figwheel seems to not want to continue

tony.kay04:11:24

IMO, figwheel probably ought to go ahead and try to emit and run your code, even though it wants to show the warning

tony.kay04:11:33

the new lein template, FYI, emits a shadow-cljs env with workspaces already set up. Figwheel main is nice, but I do prefer the non-reliance on cljsjs, the compiler cache and consistency improvements (I never have to clean source) and much better integration with js ecosystem.

tony.kay04:11:17

I’m not emitting deps.edn just yet since it’s still alpha, but I do use deps myself and like it.

grzm04:11:35

Thanks, Tony.

wilkerlucio04:11:02

@tony.kay, hello 🙂 I just imported incubator latest in a new project and I'm getting a bad dep problem:

The required namespace "taoensso.timbre" is not available, it was required by "fulcro/incubator/ui_state_machines.cljc".

tony.kay05:11:14

@wilkerlucio Give me a minute, I’ll push an update without that dep

wilkerlucio05:11:46

no worries, for now I just added the dep, just letting you know the issue 😉

tony.kay05:11:48

0.0.19 on clojars. I also removed the use of Defn for the moment, and added two (undocumented) helpers to state machines: (apply-action env mutation-helper*) which can use a fn of state-map to apply some mutation helper in a SM. (get-active-state this asm-id) Read the “current state name” from an active state machine using a UI component (this).

tony.kay05:11:05

I’ll add those docs now 😜

tony.kay05:11:25

@wilkerlucio

wilkerlucio05:11:58

cool, thanks, since you are there, what you think about one fn to pull multiple aliases at once?

wilkerlucio05:11:37

@tony.kay like a select-keys version of alias-value

wilkerlucio05:11:49

(defn alias-values [env values]
  (reduce
    (fn [out key]
      (assoc out key (fsm/alias-value env key)))
    {}
    values))

tony.kay05:11:45

There’s already aliased-data @wilkerlucio

tony.kay05:11:59

which is basically that

tony.kay05:11:06

just destructure on it

tony.kay05:11:00

sorry, perhaps my naming conventions are not conventional enough 🙂

andreas86211:11:07

Anyone got an example of how to wrap a semantic-ui form-field using Input as controller? I can use the basic version, but there are a few problems. It prints a warning and the input cursor always jumps to the end of the line. Using :default-value solves the input cursor jumping but introduces other problems because of unmanaged.

tony.kay17:11:08

If you look in the fulcro semantic UI wrappers you can see how I did it.

tony.kay17:11:00

@andreas862 it’s a bit tricky, and basically involves writing a wrapper that uses component local state tricks. Any system that does managed inputs through a round trip outside of component-local state is going to exhibit that problem.

tony.kay17:11:29

I leveraged the wrapper that Fulcro itself uses to make the main input types “work right”

tony.kay17:11:56

that technique should work for any libraries that make react components that wrap inputs.

andreas86211:11:19

I can get it to work with a basic input - But still get warnings about changing a controlled input to an uncontrolled.

andreas86211:11:51

but I don't know what to do in case of a form-field in a form. Like (com/ui-form-field {:controll Input :value text-attr ...})

andreas86211:11:23

Where a class is passed as the controller, suppose it must be wrapped somehow

tony.kay15:11:14

that warning is about passing nil as a value to an input, which you should never do. Class passed as any kind of param is just a react class. In general in FUlcro you won’t have controllers or delegate to stateful things like that…kind of an antipattern.

andreas86216:11:26

Right, just build from simple block and do logic in cljs? Sounds like a good idea. Thanks!

andreas86216:11:16

About the warning, are you talking about the :value prop? I get the same varning if I do :value (or v "")

tony.kay19:11:29

yes I am, and you should look at other inputs in that case, becaseu that is what it means

andreas86210:11:11

is this the varning you mean: "`value` prop on input should not be null". That is what I get if I pass in a nil as :value. The warning I get is: Warning: A component is changing a controlled input of type text to be uncontrolled. I have checked and devcards in semantic-ui-wrapper produces the same warning. (semantic-ui-wrapper triggers warning at first render, my warning is the first time I trigger onChange.)

andreas86210:11:55

Happens because the wrapped input has a value="something" that gets removed

pontus.colliander18:11:45

Hello! I've got a question about the keyfn for setting React keys. I'm using an id like so: (prim/factory notebook {:keyfn :id})). :id is an integer set from the database, or temporarily a prim/tempid if just created. Today I noticed that if I create a new entity with a prim/tempid, then the component will be unmounted/mounted as this tempid resolves to the real id returned from the server. This means I cannot be sure that code in :initLocalState is only run once. I verified this by changing to use an index as key, passed down in prim/computed, and then it only renders the entity once. I was wondering how people normally handle this? Or if I misunderstood something? Would ideally not use an index here.

currentoor20:11:27

@pontus.colliander I use a client created UUID for idents and :keyfns on the client

currentoor20:11:55

all my models have and :entity/id key that is just a random UUID, so then i don’t have to ever worry about tempids