Combination of Next, React & Payload with matching dependencies?

[joshhills]

Hey folks, gz on the funding to make Payload properly free!

I'd been following the website tutorial series on YouTube, and have revisited my site to update the payload dependency to take advantage of the new features (particularly embedding relationships in rich text fields).

Updating Payload demanded a newer React, but all of the faceless UI stuff used in the video series want a lower version of React. Am I being dumb, or do I just need to wait for new versions of packages to be released? Spent many hours updating the versions one by one, but it was one step forwards and two steps back each time, and each of the packages have so many dependencies, especially Payload itself, that I ended up with more warnings than I started with.

I don't want you to do the work for me, but you could maybe post about what is supported for these technologies side-by-side? In general, I think your docs could use a bit more clarity on the upgrade process, changelogs etc. otherwise early adopters will have to make a new project from scratch each time. Praying you've got a magic package.json somewhere that will fix my issues. For context, here's the package.json I'd like to update...

"dependencies": {
    "@babel/register": "^7.12.10",
    "@faceless-ui/css-grid": "^1.0.0",
    "@faceless-ui/modal": "^1.1.3",
    "@faceless-ui/window-info": "^1.2.7",
    "dateformat": "^4.5.1",
    "dotenv": "^8.2.0",
    "express": "^4.17.1",
    "jss": "^10.9.0",
    "jss-global": "^3.0.0",
    "next": "^10.0.5",
    "payload": "^0.5.1",
    "react": "^17.0.1",
    "react-icons": "^4.2.0",
    "react-jss": "^10.6.0"
  },
  "devDependencies": {
    "@commitlint/cli": "^11.0.0",
    "@commitlint/config-conventional": "^11.0.0",
    "@trbl/eslint-config": "^2.0.3",
    "@types/dateformat": "^3.0.1",
    "@types/express": "^4.17.11",
    "@types/html-validator": "^5.0.0",
    "@types/node": "^14.14.22",
    "@types/react": "^17.0.0",
    "@typescript-eslint/eslint-plugin": "^4.11.1",
    "@typescript-eslint/parser": "^4.11.1",
    "eslint": "^7.16.0",
    "eslint-plugin-import": "^2.20.0",
    "eslint-plugin-node": "^11.1.0",
    "husky": "^4.2.1",
    "jest": "^25.1.0",
    "lint-staged": "^10.0.6",
    "sharp": "^0.30.5",
    "ts-node": "^9.1.1",
    "typescript": "^4.1.3"
  }

[jmikrut]

Hey @joshhills —

Good seeing your name around here! Payload itself has actually had very few breaking changes since we launched, and they can each be seen in our CHANGELOG.md.

But, as I think you've found, a few of the faceless-ui packages have had a few breaking changes since we released that video series. I would suggest just installing the newest version of all of them, and then consult the docs to see where the APIs change. The newer versions are definitely what you want to be using as they all properly specify compatibility with React 18.

@jacobsfletch and I may be able to jump in and update the codebase for that video series so that you have some code to consult, but it might be a bit before we can get to that.

[joshhills]

Hello again 👋 😄 I had been lurking for a while as I've been busy, but I'm keen to use payload for game tech at some point so figured it was worth asking. Any time anyone needs a place for custom data to live and a nice editor for it, I've been recommending Payload.

I'll give updating another go. Do you know how well Payload handles altering schemas? Is it the case that data is lost if I change its shape? Does it linger in the database? That's the kind of thing I'm interested in knowing in terms of upgrade/migration guides - advice on how to maintain Payload in the long run. Just worried 'cause I've got a fair few articles there now (backed up of course) and last time I tried adding fields to collections it caused some strange UI issues in the admin area. Might convince people to lump in.

Feel free to spy on me @ https://github.com/joshhills/joshhills-site/
If you do get around to making a more up-to-date public repo for Payload + Next I'd be keen to see it

[jmikrut]

Ahhh thank you for recommending us!

Because of the NoSQL nature of MongoDB, altering schemas in Payload is super predictable. Data lingers in the database, even if you change the shape of the schema, and you are free to migrate your data as you need (if you need) by using Payload's Local API.

If you change a field from an array to a text field, for example, you might want to go through and migrate from shape A to shape B, but typically just adding or removing fields needs no migration at all (unless you want to).

Does this make sense?

[joshhills]

Yup, makes sense thanks! It might have been the case that I changed a field to a different type (but still the same key) without editing the data that already existed, that might have been causing some bad juju.