Skip to content

v5.0.0

Compare
Choose a tag to compare
@megamaddu megamaddu released this 12 Apr 00:47
a5f1c83

useAff refactor

Previously useAff returned Maybe (Either Error a). It no longer enforces that explicit error capturing, returning only Maybe a. This means you now have three options:

  1. Maintain the old behavior: useAff deps go becomes useAff deps (try go)
  2. Pretend errors don't exist 🤠 : leave it as useAff deps go and remove the code handling the inner Either
  3. Seem to pretend errors don't exist, but actually handle them elsewhere: this is the same as above, but using a parent error boundary component to capture unusual errors

This may sound crazy at first, but error boundaries aren't for normal application logic. If your Aff has known failure cases which you need to code for, you definitely want try, or your own data type. But in many cases, an Aff failure is just a network error, or a bug, or a hacker/typo/url-copy-paste-error. These unusual error paths don't fit in your UI components, and often just get logged to the console. Error boundaries help you capture, log, notify, etc, all in one place, cleaning up your UI components in the process (React's Suspense api is this same concept but for loading states, more below).

general api cleanup

Little things I've been meaning to do in React.Basic.Hooks for a while, as well as a few useEffect helpers inspired by halogen-hooks. The largest impact change is renaming component to reactComponent and exposing a new component which instead returns Effect (props -> JSX), also aliased as Component props. When you use this function, you are no longer constrained to using a Record, and even if you do use a Record there are no limitations on its fields. This simplifies components a bit for most PureScript-only applications.

suspense experiments

Added a few tools for experimenting with React's suspense api and concurrent mode:

  • Suspense: this api is still experimental (both the React implementation and my wrapper), so I wouldn't recommend diving into it in production just yet, but it works well enough to learn and start building libraries on top of.
  • StrictMode: put it at the top of your React app to enable stricter warnings and errors, this is to help ease existing apps in to the new requirements for enabling concurrent mode
  • Concurrent: an alternative DOM renderer which enables concurrent mode