This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-01
Channels
- # announcements (1)
- # aws (3)
- # beginners (150)
- # boot (12)
- # calva (7)
- # carry (3)
- # cider (1)
- # clara (51)
- # cljdoc (17)
- # cljs-dev (17)
- # cljsrn (1)
- # clojure (64)
- # clojure-austin (2)
- # clojure-india (1)
- # clojure-italy (10)
- # clojure-nl (4)
- # clojure-spec (42)
- # clojure-uk (63)
- # clojurescript (24)
- # core-async (23)
- # cursive (6)
- # datascript (7)
- # datomic (5)
- # figwheel-main (43)
- # fulcro (74)
- # hoplon (7)
- # kaocha (30)
- # leiningen (32)
- # mount (51)
- # nrepl (34)
- # off-topic (29)
- # re-frame (6)
- # reagent (10)
- # reitit (13)
- # shadow-cljs (66)
- # slack-help (3)
- # spacemacs (2)
- # specter (5)
- # sql (2)
- # tools-deps (51)
- # yada (13)
@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/defmutation
s 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
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?
the next arg is initial state normalized APP DATABASE IF you want to override the one your component declares
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
I can use the 3º comp
to pass lambdas, right?
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?
context free components are fine…but if they are query-free and stateless, that;s the wrong card type 🙂
So I need to use the regular defcard
to test this query/state-free components?
Can I use dc/om-root
or something like?
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.
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})
add it to reqyure
then
(defsc my-comp
[this {:keys [open? on-click]}]
(dom/button {:onClick on-click}
(if open? "+" "-")))
(def ui-my-comp (prim/factory my-comp))
(defcard my-card
(fn [state owner]
(let [st @state]
(ui-my-comp (assoc st
:on-click #(swap! state update :open? not)))))
{:open? true
:on-click #(.log js/console "???")}
{:inspect-data true})
Now working! thksNow working! thks See thread for solution 😄
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?
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 🙂