Load the ns?

@tony.kay I’ve tried requiring the namespace defining the fulcro mutations, no dice. It’s a pathom remote error though, so it seems more like the pc/defmutations aren’t found.

Figured it out! silly me, forgot to add all the resolvers into the registry!

How can I get something like (dom/span nil "    ") to work correctly?

This displays      in the html instead of properly showing blank characters

try \xA0?

also I’ve seen similar in hiccup:

(defn my-blank-component []
  [:div {:dangerouslySetInnerHTML {:__html " "}}])

How to swap states in defcard-fulcro ??

(defcard-fulcro Root-card
                ui/OpenCloseComponent
                {:open?                  false
                 :on-click  #(swap! ????)}
                {:inspect-data true})

@pvillegas12 there is an entity namespace in Fulcro that defines these…like ent/nbsp

It’s called html-entities…There’s also an events namespace that has a lot of helpers for key codes

happy to expand either of those…the events one is kind of light…I’m sure there are others that would be helpful

@souenzzo you’re aware that those cards use component initial-state if you leave the card map empty?

that isn’t an event handler…just leave that map empty

the defcard macro takes a PREDEFINED component class name:

(defcard-fulcro my-card
  OpenCloseComponent)

the next arg is initial state normalized APP DATABASE IF you want to override the one your component declares

The :onClick goes in the code of the component

never put lambdas in app state

really…never…you can put mutation symbols in app state, but things will break if you put non-serializable things in app state

that card type builds a complete fulcro app, uses the component you declare “as root”, gets the initial data from it, normalizes it into the database etc

There’s a make-root function in the cards ns to build a wrapper root for using one-off components like this

but they still need initial state to be generally functional

if you want to do that you’ll need to write a small wrapper root class for your card by hand

So I should not create "context-free" components, I should always put the "final" mutation? How? I can't have a generic button and use it in many places?

um….let’s see…could you cheat

context free components are fine…but if they are query-free and stateless, that;s the wrong card type 🙂

show me the component

So I need to use the regular defcard to test this query/state-free components? Can I use dc/om-root or something like?

no I test components in those kinds of cards all the time

I need more info about your component. If you show me the code, I’ll tell you the card

if it has no query, for example, then you don’t need an app…you just use a normal devcard…a component like that is just a pure simple React component…and you can pass callbacks via props.

The computed stuff is about components with queries

because components with queries can refresh the props separate from the parent, which would lose the computed stuff if it wasn’t marked

(because the parent makes those up, and targeted refresh need not go through the parent)

defcard-fulcro is like defcard with om-root, but it has better hot code reload behavior

(defsc my-comp
  [this {:keys [open? on-click]}]
  (dom/button {:onClick on-click}
              (if open? "+" "-")))

(defcard my-card
  my-comp
  {:open? false :on-click #(.log js/console "???")}
  {:inspect-data true})

When I try to use dc/om-root I get Use of undeclared Var om.core/root

you the fn form for normal react

not Om OR Fulcro

(defcard my-card
  (fn [atom _] ...))

then pass the on-click as a prop to the component as code

not as something stored in the atom

exactly

What is a good way to go about testing components in fulcro?

Example test cases: - Interaction: Click on a button and expect something to happen - Given different states what should the component display?

Testing mutations and functions is straight forward but I’m not sure how to tackle testing components themselves

The only similar section of the book I’ve found on this is http://book.fulcrologic.com/#VisualRegression

@tony.kay any thoughts on this?

@pvillegas12 this should be no much different from testing pure React, the friction is probably in align the tools, AFAIK there is nothing done, so you have to write the wrappers yourself

@wilkerlucio what do you use to test fulcro components?

currently I do mostly two types of tests, one is for rendering, another for mutations

the mutations should be strait forward, you create some initial state, trigger the mutation and look at the atom after that, so you check if the data is changing as expected

right

for the views, I'm doing generative testing, given in fulcro all the data uses namespaced keywords, its quite easy to generate random data to render a widget

so I render a lot of random data (and include some bad information, like possible parser errors and nils everywhere)

than I render and check if no exception was thrown

in Pathom you can find helpers for the generative part: https://github.com/wilkerlucio/pathom/blob/master/src/com/wsscode/pathom/gen.cljc#L211-L213

this for example takes a component and returns a test.check generator that will get you random props for it

do you test interactions within the component?

nope

I assume that all that transactions can do is change state

the state changes are covered by mutation specs, and any type of render can end up in one of the cases of the generative thing

yeah, I guess we end up going back to philosophically what we should be testing in components 🙂

yup, I had put some time thinking about it, and tried a couple of approaches, I still think we have a lot to explore in this space, but I'm happy with this current setup, it gets a good sanity overall check, prevents people from simple mistakes (like trying to render a keyword by accident) @pvillegas12

and it's easy to maintain, this is the code for testing a component:

I really like the snapshot testing too to combine with the above

(ws/deftest test-macro-content-component
  (ts/check-component {::ts/component ui.spotlight/MacroContent
                       ::ts/gen-env   gen-env}))

yeah, the snapshot is interesting, it just takes some time to run, depending on the number of components you have it can be a burden

What does that do, the generative testing approach?

The magic goes in what ts is 🙂