feat: Add @cerbos/react package

[hasanayan]

This is an initial/draft PR to agree on some of the concepts. It's lacking documentation and testing and some areas that are subject to change.

I am opening this to be able to discuss the what @cerbos/react should offer and some other issues on the environment (linter rules etc)

[hasanayan]

@haines where do you think we should test this package? in packages/test with the rest of the packages? We will need to extend the test config with jsdom and @vitejs/plugin-react but I believe that should be OK. Do you have any other opinion on this?

[haines]

We will need to extend the test config with jsdom and @vitejs/plugin-react but I believe that should be OK.

Yeah, that's fine. Although it's maybe less convenient than colocating the tests with the source, the rationale for keeping the tests in a separate package is that it forces us to only test against the publicly-exposed API of the other packages, and it ensures that we don't accidentally ship the tests in the packages we publish to npm.

[hasanayan]

@haines I think docs and the actual code is ready for final review, I'm moving on to testing

[haines]

Code looks great. I've made some minor suggestions for the docs on hasanayan#2. We'll also need to add a changelog but we should do that after #18 lands because I changed the format 🙈

[hasanayan]

@haines added tests with a placeholder test for testing request cancellation, I'll wait until you merge your PR and I'll add the test.

I also added changelog.yml file but I am not sure it's correct. Btw I don't know what should be our initial version, an alpha or beta maybe? For now it's set as 0.0.1 in package.json

Also, apparently my brain is still in weekend-low-power mode 😄, I somehow thought your docs PR was actually a direct commit (you don't even have access, I know ^^) and I force pushed and removed it so I manually took those changes in 🤦🏻 But anyway I saved you a rebase 😄

[haines]

This is looking great!

[hasanayan]

@haines all done but; I broke my back trying to get React to complain about setState call after unmounting during tests (without if (!abortController.signal.aborted) check in the catch block) so that I could test that doesn't happen. Unfortunately I could not succeed. But I am testing that we always pass an AbortSignal with the requests and the signal is aborted on unmount.

[haines]

Minor but here and below you could probably avoid the non-null assertion because the test will still fail if it is undefined:

Suggested change

	// eslint-disable-next-line @typescript-eslint/no-non-null-assertion
	expect(abortSignal!.aborted).toBe(false);
	expect(abortSignal?.aborted).toBe(false);

[hasanayan]

I thought the same but no-unsafe-assignment rule is not happy about that (no configuration options). I chose this one to suppress

[haines]

Ah, ok... weird!

[haines]

I broke my back trying to get React to complain about setState call after unmounting during tests (without if (!abortController.signal.aborted) check in the catch block) so that I could test that happens. Unfortunately I could succeed. But I am testing that we always pass an AbortSignal with the requests and the signal is aborted on unmount.

Yeah, sounds painful - I think we have good test coverage of the abort behaviour between the tests I wrote for the client and the one you have added here, so I'm happy enough with that!

[haines]

Awesome!