jfdk

I built the guts of this about a year ago to help keep on top of my team's tasks, track sprint planning, and keep on top of pending code reviews. Definitely targeted more towards Tech Leads and Product Managers. I found it useful to use every day, so I spent the time to productize it a bit more formally. Since, more people on my team at work have been using pretty much daily and found it useful. I hope you do too!

This is my first side-project I've taken the time to productize and I could definitely use your feedback!

  - Would you use this? If so, would you pay for it?
  - If not, what do you use to stay on top tasks now?
  - What other problems do you have with project management that isn't already being addressed by the gazillion tools out there?

If you do try it out, I'd love to hear more about any UX issues you run into! (I'm sure there's plenty)

I think this largely depends on how much money you are chasing and your aspirations.

I care about money not because I want to have lots of things but because I want the freedom to work on my own ideas (without selling my soul to a VC). A certain amount of money early in life can greatly change your trajectory, for better or for worse. It just takes discipline.

This is actually pretty huge. #1 complaint/barrier/hate with getting started with React is all the tooling to do it "the right way"

Kudos to React team for bringing a superior pattern and making it actually practical to use.

I've found beforeEach breaks down super quickly as soon as you need to change the input props. Keeping things as purely functional as possible also helps manage complexity when writing tests in a large suite. You don't have to trace through all the beforeEach of each describe/context block. That said we use a healthy combination of both, as with everything know when to use the right tool.

If your application has few or very simple interactions then this may make sense. If it does have complex interactions (I consider a text input updating a model field as complex) then I think tests are necessary, especially if working with a team. You want to know when you break things.

This becomes even more important if you're developing generic UI components that may be re-used in different scenarios throughout your app or company. These types of library components need to be well tested as they often have more complex interactions and are going to be used in potentially very different ways.

Good to know, will update the examples when I have time. Not sure I'm a big fan of it though, doesn't seem as clear to a React noob what is going on with ref?

JS tests like this are so stupid cheap that we still write them for even the most basic test. Not sure I'm convinced it's worth it yet and I might regret it the first time we refactor a larger reducer.