Fork me on GitHub
#re-frame
<
2021-04-23
>
apt18:04:53

Hey folks. I’m trying write a unit test that dispatches an event. The event is dispatched like this in the view ns:

(r/dispatch [:timeline/init (r-dom/dom-node comp) {}])
I need to use dom-node because the event creates a new object (a timeline from the vis js lib, to be more precise: https://visjs.github.io/vis-timeline/docs/timeline/) The issue is that I don’t know how to simulate this dom-node in the unit test. I tried to use (.getElementById js/document “app”) and pass it to :timeline/init but it gets nil.

p-himik18:04:27

If you test in a browser, you can always create a new element. But since this particular event ends up mutating something in the DOM in an explicit way, such a test might affect other tests.

p-himik18:04:17

Ah, actually, I might be wrong, because by default that element is not inserted: https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement But you might need to insert it into the document if vis-timeline expects it to be there.

apt18:04:13

To be more specific, the event does this:

(new vis/Timeline
                             node
                             items-dataset
                             groups-dataset
                             (clj->js opts))
where node is something coming from the event parameters (when it’s called from the view, (r-dom/dom-node comp)). This inserts timeline in the document as a child of node.

p-himik18:04:58

Ideally, you should do it in an effect handler, not an event handler.

apt18:04:01

Yeah, I considered that. But setting it as an effect wouldn’t solve the original issue of the test, right? I’m not sure I got your previous suggestion.

p-himik18:04:40

It would allow you test the event handler in isolation, if it does any relevant work apart from calling (new ...).

p-himik18:04:01

My previous suggestion is to use document.createElement instead of document.getElementById.

p-himik18:04:09

Only for tests, of course.

apt18:04:35

Got it. Yeah, the event does other things too. I’ll see what I can do. Thanks.

eval-on-point19:04:05

There is some discussion in the #lsp about adding code navigation to re-frame registry and a few questions are popping up. Light testing shows that the two scenarios below work in re-frame, but it is unclear whether they are defined behavior: 1. Is it specified whether you are allowed to register the same id to different kinds? (e.g. Could I register :start as a subscription and a coeffect?) 2. Is it specified whether id's need to be keywords? For example, registering 'a-symbol as an event handler works.

😎 3
p-himik22:04:00

1. You can. All handler kinds are independent. You can use :start as a subscription ID, an event ID, an effect ID, a coeffect ID - all at the same time. 2. IDs can be anything.