Live data from Hacker News

Tremor – The React library to build dashboards fast

tremor.so

71–80 of 84 posts

Re: Tremor – The React library to build dashboards fast

#71

I started a react component library project that has been going for 4 years now and gets about 40k downloads a month. If it wasn't for my test suite, things would have been a giant mess long ago and I probably would have abandoned it. I can't think of doing a react project without a test suite because over time, any dependencies you have (including on react) will end up breaking things in ways that you don't know. Wi…

I have yet to see a good frontend test, but I'm waiting to be enlightened. For the most part, it just seems to be things like "if they click this button, make sure this div is gone." That smells like a test double to me.

You should take a look at the end to end testing tool named Cypress. As an end to end test it goes beyond click this check that. As an end to end test it will make sure that your app with its features works seamlessly for the user and that your React components work well together. Cypress is amazingly built and it is super fast to write tests with it. It’s easier to debug and seeing the robot doing the tests is pretty cool. For me it’s a must have.

You can check:

https://youtu.be/BQqzfHQkREo https://youtu.be/OVNjsIto9xM&t=28m06s https://youtu.be/VvLocgtCQnY

Re: Tremor – The React library to build dashboards fast

#72

Earlier quoted context omitted.

Part of the complexity of integrating a form library with a ux library is passing all of the correct properties around between the two. In this case, I wasn't doing that correctly and it resulted in a bug where disabled was not being set correctly. Someone filed a bug. The bug was fixed and a test was written to ensure that this doesn't happen again in the future. You can read the history here: https://github.com/loo…

> if you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it. We all write bugs, we're human and it's hard to think of everything all of the time. My point was, when we make a thinking error that causes us to write a bug, that same thinking…

If you practice test-driven development, the mindset is slightly different.

Humans can't think of everything all the time - TDD guides you to think about one thing at a time.

No one is sitting there adding a disabled prop on their component that then disables an input for no reason. You had intent when writing it. It's possible that a co-worker distracted you, or you went for a break, or you went down another rabbit hole, and ended up skipping disabling the input based on the prop.

If you're practicing TDD, you would have written a failing test before creating the disabled prop. That test will continue to fail until the productive code has been written. It helps to protect against those thinking errors in the first place.

Re: Tremor – The React library to build dashboards fast

#74
post #71

Earlier quoted context omitted.

I have yet to see a good frontend test, but I'm waiting to be enlightened. For the most part, it just seems to be things like "if they click this button, make sure this div is gone." That smells like a test double to me.

You should take a look at the end to end testing tool named Cypress. As an end to end test it goes beyond click this check that. As an end to end test it will make sure that your app with its features works seamlessly for the user and that your React components work well together. Cypress is amazingly built and it is super fast to write tests with it. It’s easier to debug and seeing the robot doing the tests is prett…

Right, that is the one I was thinking about. Thanks!

Re: Tremor – The React library to build dashboards fast

#75
post #72

Earlier quoted context omitted.

> if you're working with people who randomly 'forget' things while they are doing development, then I guarantee that you're working with people who also write buggy code. In fact, in this case, it was ME who wrote that buggy code. I own it. We all write bugs, we're human and it's hard to think of everything all of the time. My point was, when we make a thinking error that causes us to write a bug, that same thinking…

If you practice test-driven development, the mindset is slightly different. Humans can't think of everything all the time - TDD guides you to think about one thing at a time. No one is sitting there adding a disabled prop on their component that then disables an input for no reason. You had intent when writing it. It's possible that a co-worker distracted you, or you went for a break, or you went down another rabbit…

I am all about TDD, but in this case, I'm integrating two third party libraries that have many many features.

There is almost no way to even know what features they have, especially over time. Imagine that MUI added disabled in a new release and now my project isn't implementing it during an upgrade. TDD wouldn't have caught that.

Re: Tremor – The React library to build dashboards fast

#76
post #69

Earlier quoted context omitted.

The developer that forgets to make disable work, will also forget to write this kind of test for it. Once the behaviour is added, it'll never be randomly removed again so the test isn't needed then. It looks nice but never helped find a bug.

An example where it’s helped me personally is when migrating from Angular Material to Ant Design. The test cases gave me confidence the expected behaviour was preserved

Very good example. Tests are all about 'delta'. Changes over time. They bring confidence over delta.

Re: Tremor – The React library to build dashboards fast

#77

Earlier quoted context omitted.

I've given an example of a whole repository, that is now 4 years old, full of the types of tests you're talking about. It isn't that hard. If the desired behavior is changing, then the test should fail and yes, you need to rewrite it. That's how testing works.

It's not hard, but they just make the build of our monorepo take longer and longer without finding actual bugs, in my experience. I feel most unit tests should be commented out once the thing under test is done.

You are arguing against tests. It is not a winnable argument.

Re: Tremor – The React library to build dashboards fast

#78
post #66

Earlier quoted context omitted.

It probably works ok for a solo project but IME with large scale codebases snapshot tests are awful. You update some implementation detail of a common shared component and suddenly 5000 tests break despite the look and behavior being unchanged.

This has been my experience in the past with a heavily snapshot covered codebase. Class names can change, the structure of your HTML can change, the underlying CSS can even change and the end result is still the same because you were just refactoring. At a large enough scale it can be painful to have hundreds of snapshots break for a simple change - especially when you add required code review by others into the mix.…

Give people the tools to easily update the snapshots and read the diff's of PR's (github is quite good at this imho).

Re: Tremor – The React library to build dashboards fast

#79
post #47

I've gotten so jaded on these "batteries included! everything you'll ever need!" component libraries over the years. Inevitably you'll run into a component that is half-baked or incompatible with your architecture, which forces you to install a 3rd party alternative. Then it happens again. And again... Eventually you're left pulling in this huge library with 2MB of CSS just for the four components you're still using…

I've gotten jaded with that approach too. The same thing happens, just on an individual component scale. (The number of times I've gotten written into a corner with $dropdown_component is too damn high.) My pendulum has swung to do it all yourself with ample links in the source to other projects on GitHub for inspiration.

[deleted]

Re: Tremor – The React library to build dashboards fast

#80
post #66

Earlier quoted context omitted.

This has been my experience in the past with a heavily snapshot covered codebase. Class names can change, the structure of your HTML can change, the underlying CSS can even change and the end result is still the same because you were just refactoring. At a large enough scale it can be painful to have hundreds of snapshots break for a simple change - especially when you add required code review by others into the mix.…

Give people the tools to easily update the snapshots and read the diff's of PR's (github is quite good at this imho).

I kinda think "just blindly update the snapshots" is teaching the wrong lesson. We removed them from our projects and haven't missed them.

Visual diffing, cypress >>>> snapshots IMO.

Post reply on HN