Skip to content

Releases: purescript-react/purescript-react-basic-hooks

v8.2.0

30 May 22:51
2a0b598
Compare
Choose a tag to compare

v8.0.0

24 May 07:37
Compare
Choose a tag to compare
  • PureScript 0.15 (@ptrfrncsmrph)
  • memo' (@andys8)

v7.0.1

25 Nov 00:45
Compare
Choose a tag to compare
  • Fix a runtime error edge-case when using useState with a function type (thanks @mikesol)

v7.0.0

10 Mar 17:56
5db908c
Compare
Choose a tag to compare

PureScript 0.14 support!

v6.3.0

02 Feb 19:28
c71def7
Compare
Choose a tag to compare
  • Add & type operator for reversing hook chain order, as it can be easier to understand when the hook chain matches the layout of its related do block
  • Add Show instance to ResetToken for use in things like React keys

v6.2.0

30 Sep 21:02
5e43ca3
Compare
Choose a tag to compare
  • Add missing IxMonad and Monad instances to Render (@cdepillabout)

v5.2.0

30 Apr 09:18
d79a9b8
Compare
Choose a tag to compare

v5.1.0

29 Apr 01:06
6774426
Compare
Choose a tag to compare

v5.0.1

29 Apr 01:08
ed479a3
Compare
Choose a tag to compare
  • fix useEffectAlways (@ptrfrncsmrph)

v5.0.0

12 Apr 00:47
a5f1c83
Compare
Choose a tag to compare

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