Redwood v4.0.0 Upgrade Guide

[dennemark]

Now that v4.0.1 is out, I read through the upgrade guide again and wondering about the fetch part.

@dom

Switch from cross-undici-fetch to @whatwg-node/fetch

This is for api side correct? I read nodejs18 implements undici for fetch
GitHub - nodejs/undici: An HTTP/1.1 client, written from scratch for Node.js
Is there any advantage in using @whatwg-node/fetch?

[AlexRoosWork]

Kind of an edge case question. I use storybook and have a LoggedInDecorator for mocking the logged in state. Previously, this file looked like this.

import { AuthContext } from '@redwoodjs/auth/dist/AuthProvider'
export const LoggedInDecorator = (Story) => (
  <AuthContext.Provider
    value={{
      isAuthenticated: true,
      roles: ['Admin'],
      currentUser: {
        id: '123',
        username: 'Alex',
      },
      hasRole: (roles) => {
        return true
      },
    }}
  >
    <Story />
  </AuthContext.Provider>
)

Now, I have just removed the @redwoodjs/auth package. So the import has to change. I looked a bit in the code and found that I can export a thing called AuthContext from the createAuth() function. So in my web/src/auth.ts I just destructed it from the function and am changing the import to src/auth.

However, <AuthContext.Provider /> does not seem to work properly in storybook, since I get an error in storybook with:

Cannot read properties of undefined (reading 'Provider')
TypeError: Cannot read properties of undefined (reading 'Provider')
    at LoggedInDecorator (http://localhost:7910/main.iframe.bundle.js:50932:119)...

Any advice would be greatly appreciated!

[razzeee]

I’m seeing slightly different behavior from mockCurrentUser, which doesn’t seem to reset anymore?

I have a test file, that has four tests. Two logged in, two not logged in.

After running the logged in ones, I now need to call mockCurrentUser(null) before running the non logged in ones. I guess I could just revert the order, but I’m unsure if that change was intended. (probably an upstream change)

[thedavid]

Looping in @Tobbe

Most likely not intended but depending on how you wrote your test could also be a “fix” even though behavior changed. Possible to share a snippet?

[dom]

@AlexRoosWork definitely not an edge case, an oversight on my part. We made complimentary code changes to mocking auth in tests and Storybook, so I should’ve highlighted this.

One thing that concerns me a bit about your code example is that you import from /dist, but I think my suggestion below still applies.

Based on what I can infer from the code changes, I think there’s good news, in that the new way of mocking auth in web-side tests and in Storybook is simpler. Mainly, you don’t need a LoggedInDecorator of sorts anymore. Instead, you just have to mock the current user via mockCurrentUser, and useAuth will more or less simply return what you mock.

Say in your home page, you import the useAuth hook from 'src/auth' and use its props to conditionally render like so:

import { useAuth } from 'src/auth'

const HomePage = () => {
  const { isAuthenticated } = useAuth()
  return isAuthenticated ? (<p>You are authenticated</p>) : (<p>You aren't authenticated</p>)
}

export default HomePage

To see the “You are authenticated” state, you’re going to have to mock the current user in the story:

import type { ComponentMeta } from '@storybook/react'

import HomePage from './HomePage'

export const generated = () => {
  // You need to mock the current user here; and this function is globally available in stories
  mockCurrentUser({ name: 'jtoar' })

  return <HomePage />
}

export default {
  title: 'Pages/HomePage',
  component: HomePage,
} as ComponentMeta<typeof HomePage>

I’ll try to follow up with a more comprehensive example, and will let @Tobbe chime in cause I could’ve gotten some details wrong, but maybe give that a shot @AlexRoosWork and let me know how it goes?

[dom]

@dennemark yes this is for the api side. And between those two packages, I’m honestly not sure if one has an advantage over the other, but you should definitely move off cross-undici-fetch if you can. I don’t think it’s broken, but it isn’t receiving updates anymore.

[dom]

Haven’t looked further into it yet, but @razzeee I’m confirming that I’m also seeing a call to mockCurrentUser in one it block carry over into another on v4.

[arimendelow]

This has broken webauthn - I tested this with a brand new Redwood project (noting that the docs have not been updated.) and the issue persists. It looks like it’s sending back the page’s own index.html instead of the proper response, for some reason?

Post 4.0.0:

Pre 4.0.0:

I tested this in production as well.

@rob you helped with webauthn issues in the past, maybe you have some ideas here?

[arimendelow]

Opened an issue as well: [Bug?]: Webauthn not working after 4.0.0 · Issue #7637 · redwoodjs/redwood · GitHub

[dom]

I tested webAuthn but I’ll try again—you just set up a new project, not upgraded an old one?

Update: confirmed with a new project.

[arimendelow]

yeah, I did both - same issue in both. oh I see you opened a PR that fixes this, thanks!

[zygopleural]

Great write up @dom - only just got round to doing it!

[tbay06]

Just want to add that for this upgrade useRequireAuth also needs the authDecoder passed in as a parameter, the same as createGraphQLHandler - couldn’t find that change documented anywhere