Cory House Profile picture
Jan 8 3 tweets 2 min read
Problem:
TypeScript errors are typed "unknown".

Solution:
Throw custom errors. They're easy to inspect.

How:
1. Create an ErrorBase class.
2. Create an instance ErrorBase for each feature and specify the feature's potential errors.

#typescript export class ErrorBase<T ex...// Throwing a UserError exa...// Catching a UserError try...
Note that the base class also enforces including a cause property, so the original error's info remains available.

Here's why cause is handy:
I've used a similar pattern on previous projects. It's quite helpful.

Credit to @KolbySisk who wrote a post that gave me the idea of creating the base class.

See his excellent post for more info on creating custom errors: engineering.udacity.com/handling-error…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Cory House

Cory House Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @housecor

Jan 10
Pre-commit hooks are a waste of time.

Why? Because they enforce standards too early. Pre-commit hooks make us wait for a quality check on every commit.👎

The code shouldn't need to be "right" to save my changes.

The code only needs to be right before merge.

Solution? Use CI.
I should be able to *instantly* commit anything.

This CI server assures I can’t merge broken code. And the CI server avoids wasting my time waiting for premature quality checks on every commit.

The CI server assures the code is worthy before I can merge it. 👍
Tip: If you’re tired of waiting for a pre-commit hook on every commit, do this:

git commit -m “commit message” --no-verify

The no-verify flag disables commit hooks.

And as a long-term solution, assure CI is configured. Then you can safely delete all pre-commit hooks.
Read 6 tweets
Dec 28, 2022
13 ways to be a lousy developer:

- Don't volunteer to help others.

- Don’t try to get better or learn.

- Don't test code before opening a PR.

- Rubber stamp PRs, or don’t review them at all.

- Don't be proactive. Only act when told to do so.

1/5 👇
- Write hacky, buggy, hard to understand code.

- Often fail to finish work. Give up if it’s hard.

- Don't use personal judgement. Only do precisely what you're told.

- Be hard to contact during the day and frequently unavailable.

2/5
- Open PRs that take more time to fix than it would to just redo it.

- Frequently complain. But don’t suggest or implement improvements.

- Consistently take far longer than expected to finish tasks.

- Fail to take responsibility. Blame failures on the system or others.

3/5
Read 5 tweets
Dec 22, 2022
3 seemingly unrelated items that are deeply connected:

1. Career
2. Health
3. Finances

If I only optimize one or two of these, I limit my potential.

Here’s why…
Optimizing my career improves my finances.

Optimizing my career improves my health too - Improving my effectiveness at work reduces my stress.

If my job is impacting my health, getting better at it increases my bargaining power (work flexible hours, remote, so I can workout).
Optimizing my health improves my career. Healthy people miss work less, are more focused, driven, optimistic, and think more clearly.

Optimizing my health improves my finances. It avoids expensive health care issues and time off work.
Read 10 tweets
Dec 18, 2022
A unit test shouldn’t:

🚫 Call a DB
🚫 Run a browser
🚫 Make an HTTP call
🚫 Rely on stuff on other machines

A unit test should pass without a network connection.

There’s nothing wrong with doing such things in a test. But if a test does these things, it’s not a unit test.
One more thing:

The definition of "unit test" matters.

Why? It gives us a clear goal.

A unit test's goal: Test in isolation, quickly.

Other types of tests like integration, end-to-end, performance, etc, are useful too. But they have different goals.
Some said "I just care about fast vs slow tests."

The problem is, "fast vs slow" is imprecise.

Some may think a DB call is fast. It's not. It's much slower.

So, specifying what a unit test *shouldn't* do helps assure the test is fast, isolated, and reliable.
Read 4 tweets
Nov 30, 2022
I’m a big Cypress fan, so I’m shocked to say this: I just switched to @playwrightweb.

Here are 16 reasons I switched:

1. WAY Faster. ~2X faster with 1 core. ~6x faster with multiple cores (uses multiple workers)

2. Tests multiple browsers in parallel.

1/5

Comparison:👇 ImageImage
3. Uses browser automation APIs, so it's efficient.

4. Simple config, with thoughtful defaults.

5. No globals.

6. Uses plain async/await.

7. Elegantly tests across domains. No extra complexity required. (see pic in first tweet)

8. Supports TypeScript out of the box.

2/5 👇
9. Built-in support for running the app before the tests.

10. Rich built-in locators including testing-library style queries, and layout-based selectors like near, below, above, right-of, etc.

11. Persist session data for reuse across tests with 1 line of code.

3/5 👇
Read 7 tweets
Oct 31, 2022
⚛️10 reasons to prefer useReducer over useState:

1.  Separates reads from writes.

2. Avoids useState pitfalls. You should use functional setState to safely update state using existing state. With useReducer, you can't mess this up.

3. Easy to test. It's a pure function.

#react
4. Typically simplifies useEffect by removing unnecessary dependencies

5. Centralizes state writes, which is often easier to understand

6. Elegantly handles related state (Note you can also use objects with useState to compose data that changes together)
7. Can easily store the entire state tree in localStorage

8. Can pass dispatch down to avoid passing many callback funcs on props

9. Can easily log all actions since they're centralized

10. Moving state management to a separate file makes the component easier to understand.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(