Fork me on GitHub
David Pham09:08:41

The third form of components in reagent can get a constructor key. In the documentation they say you provide a function with 2 arguments, but can you provide a 3 arguments functions with the last one being the possible context?

Lone Ranger13:08:49

When you say context, do you mean react context or do you mean an encapsulating closure?

Lone Ranger13:08:06

@neo2551 looking at the documentation, it would appear that you can provide an encapsulating clojure by wrapping the form-3 component in a let:

David Pham13:08:57

@goomba I meant a react context

Lone Ranger13:08:45

I took a glance through the source code and I don't see anything explicitly mentioned about it. My guess is it's exposed via life-cycle methods if you're already familiar with react, but I'm not a react expert.

Lone Ranger14:08:42

does anyone have any ideas how to recursively expand form-2 components for testing?

Lone Ranger14:08:10

:thinking_face: actually I'm not sure if that makes sense for unit testing


What are you looking to do @goomba?

Lone Ranger18:08:05

testing the hiccup generated by components 🙂

Lone Ranger18:08:46

but then I realized that it doesn't make for good unit-testing since once you start dealing with reactions now you're off in side-effect territory


To get you on the right foot, the approach you are looking for is not testing the hiccup generated, but that the component renders to the dom correctly. So my recommendation is checking out how the JavaScript community tests React. The general idea is: 1. Define a component 2. Instantiate the component 3. Render the component 4. assert your component renders/behaves as you expect e.g.

(defn my-comp [] ...) ; define component

(deftest my-comp-renders 
   (let [comp [my-component props]]) ; instantiate component
          container (render comp)] ; render component to a dom element like you would in your app
     ; assert your component renders/behaves as you expect

Lone Ranger18:08:24

So my question is, what if you have internal reactions?

Lone Ranger18:08:44

Haven't we kind've gotten away from unit testing at that point? If our containers are only prop driven, that's no problem. But if we're using reactions internally then we'd have to set up the ratom state prior to initiating the test, which could get messy

Lone Ranger18:08:07

One obvious solution is develop only using props but that's not always practical/performant, depends on the situation


Unit tests are one tool and in this case was serving as a simple example of the basis of how React tests work. I prefer integration testing in general, but it also depends on what I am doing. Right tool for the job 🙂 As for how to test stateful components, that depends on how your state is structured/what you are doing. e.g. is it a screen and we want to test that an API call hydrates the component? or is it a simple component that just happens to track some internal actions like a counter?

Lone Ranger18:08:59

solid points all around, I'll give it some thought. I've managed to successfully set up a wonderfully data driven workflow and the only part of my application that isn't fully testable it the hiccup, so far. Was hoping to be able nail down that last part too!

👍 4

Again, even for a stateful component you don’t test the return value of your Reagent component, you test how it renders to the DOM. Testing state is than a matter of mocking out an API call, or programmatically interacting with the component and then ensuring that the component is behaving as you expect. Its a different mentality for sure.

Lone Ranger19:08:22

interesting... so, looking at the code you posted, lets say I have a global ratom that manages application state and drives a lot of the reactions. Would I have to populate this global ratom appropriately, or is the idea that I would somehow mock out the reactions?

Lone Ranger19:08:02

perhaps I'm also misunderstanding -- is "rendering" here in reference to the react virtual DOM or we mean actually rendering to the DOM -- in which case I would think that selenium would be the tool of choice. (I'm saying this without any real practical experience with selenium)


> Would I have to populate this global ratom appropriately, Yes. Given that you have this DB like object in the front end, you can init it with data and query the DOM/your app to see how your app behaves. (assuming it lives outside of components). If it lives inside components you have to see how that atom gets populated and then mock that out. > is “rendering” here in reference to the react virtual DOM In this case “rendering” means rendering the actual DOM. The virtual DOM is for React. > selenium would be the tool of choice. No, Selenium is for E2E tests and I would highly recommend staying away from it as the tool is dated. Take a look at Cypress instead. E2E tests do not replace integration/unit tests (I make a distinction between integration and E2E on purpose). The latter run faster, are less resource intensive and will allow you to test your data driven components more naturally. Ideally, you want to use both. The focus of E2E is that your entire system is working end to end. There is overlap so it is up to your to decide how you want to use these tools

Lone Ranger19:08:56

outstanding... thank you for the practical experience, I'll put it to best use 🙂

👍 4
Vitaly Kramskikh18:08:32

Folks, I'm trying to use reagent 0.8.1 with react 16.9 and I'm getting warnings about componentWillMount for lots of my components. It seems that reagent creates componentWillMount implicitly. Do I understand correctly that there is no way to use react 16.9 with the latest reagent without these warnings? If yes, does anybody know if it's planned to release the next version of reagent soon? I see the support for react 16.9 was merged 10 days ago, but there is still no release

👍 4