How to Build Resilient JavaScript UIs

https://www.smashingmagazine.com/2021/08/build-resilient-javascript-ui/

by Liriel • 5 years ago

42 27 5 years ago

ramesh315• 5 years ago

  if (
    typeof stripe === "object" &&
    typeof stripe.handleCardPayment === "function"
  ) {
    stripe.handleCardPayment(/\* ... \*/);
  } else {
    logger.capture(
      "[Payment] Card charge — Unable to fulfill card payment 
      because stripe.handleCardPayment was unavailable"
    );
  }"

This is silly. With modern JS tooling you should never be worried if a function exists; that should be caught at compile time.

graftak• 5 years ago

To add to that, validating response types[1] beyond the I/O boundaries is also rather silly.

[1] Second example here: https://www.smashingmagazine.com/2021/08/build-resilient-jav...

ramesh315• 5 years ago

Right. Rather than checking if the array exists, his hook should just always be returning an empty array. The map would then do nothing and his component would never even try to render.

rglover• 5 years ago

You're making the assumption that the person reading this is using modern JS tooling (not just writing vanilla JavaScript). What's proposed here, though verbose, is a good way to teach type checking in JS without a dependency.

Tooling is a crutch. We should be teaching more of the above, not less.

cnity2• 5 years ago

I agree, though I'd settle for:

`if (stripe && stripe.handleCardPayment)`

(I know the behaviour isn't identical, but checking the actual type is pointless in this case)

jalino23• 5 years ago

its naive to think that everyone has the luxury to use modern js tooling.

jtvjan• 5 years ago

How would you know at "compile time" whether a library failed to load?

ramesh315• 5 years ago

How would you know at "compile time" whether a library failed to load?

Imports and Webpack. I cannot imagine externally loading a payment SDK like that in this day and age.

phillipseamore• 5 years ago

The Stripe SDK could be loaded from stripe.com, the user might be running extensions that disable Stripe. Nothing wrong with making sure that a critical operation can be run.

eatonphil2• 5 years ago

Not trolling: counting on compile time checks in Javascript is the opposite of what I think of as resilient.

Although I'm a huge fan of TypeScript and use it and a bundle in all my UIs, you cannot guarantee that everything was typed correctly or that things haven't escaped being typed.

Sometimes I wonder if the right thing is to actually guard every object from being undefined like this sample. It does seem crazy.

This is basically a problem for every language with metaprogramming/eval/LD_PRELOAD: you can't necessarily truly count on things being defined like you think they are. That also starts getting pretty paranoid but again the topic here is resilience so should you ignore that things can/actually do change under the hood when you don't expect?

chrismorgan2• 5 years ago

Error-handling code is the buggiest code out there. You should strongly avoid unnecessary error-checking stuff, because how you handle it will commonly be worse than having just done nothing. As a related example, validating email addresses badly (forbidding valid email addresses) is probably worse than doing nothing (accepting invalid email addresses).

This is an excellent example of necessary error-checking stuff; user-agent feature detection (which includes the browser’s baseline functionality which is basically a completely uncontrolled third-party library, the worst situation by far) is another good example. But it’s extremely easy to take it too far. Any library stuff that gets bundled into your code, you should prefer compile-time to runtime type-checking. But anything outside, yeah, then you have to decide.

city413• 5 years ago

The code that you locally control and own you can have strong confidence in and type checking can be very valuable. Anything brought in at run time (say a third party lib loaded via a script tag or data fetched from an endpoint) you have no guarantees at all about what it will actually be. You can still use TS to your advantage here and type the third party code/data in such a way that will cause the compiler to encourage you to be more defensive, such as using the unknown type.

schwartzworld• 5 years ago

If you aren't personally in control of the backend, you have to assume that your backend is occasionally going to have bugs or breaking changes or unexpected information. If unexpected data is going to cause your app to crash or work wrong, IMO you absolutely need to have a plan for spotting those errors and failing gracefully.

madeofpalk• 5 years ago

It depends on how much you want to lie to yourself.

At the end of the day, Javascript is still a dynamic language where you might be loading dependencies from outside your build chain. It's up to you to decide how defensive/safe you want to be I guess. I don't think there's a wrong answer.

runawaybottle2• 5 years ago

And this is the dirty truth about Typescript in modern frontend. The truth of the matter is, the true type of everything that hits the backend is type any, because it could truly be anything. You can run from it all you want, but compile time checking won’t save you from the JavaScript gods (who are merciless). Better get those run time null checks in.

I dare you to connect to a real time api and rely on your type checking, it ain’t gonna happen.

runawaybottle2• 5 years ago

Well, have you ever built something real? You sincerely believe that at runtime an API call will always be what you think it will be because you set the type in Typescript?

I don’t want to be that guy, but there’s no way you built anything real.

‘hey guys, I totally set the type of the api response to String, so it’s always going to return a string, right right?’.

Wait till all your compile time type checks don’t mean jack shit on prod when multiple endpoints just do something unexpected. Now you have a UI that didn’t gracefully handle any of it, and have fun extolling the virtues of type checking to the business — ‘but it says right here, it’s a String!’.

And what if it’s not? The problem with induction.

city413• 5 years ago

This can be true of code you control. But third party code and remote fetched data can be anything at all at run time.

onion2k• 5 years ago

Testing things are available before you use them is just basic progressive enhancement. The cost of doing it is so minimal, and the improvement to the user experience so great, that there's no reason not to.

reader_mode• 5 years ago

I think this code is bad because it uses if/else (it should be if not abort) and it only tests/handles one error case and the log is not very valuable, would be much better to wrap the block in try catch and capture all exceptions (should be fairly obvious from exception that stripe.handleCardPayment doesn't exist)

How to Build Resilient JavaScript UIs

Related Stories