←back to thread

214 points stefankuehnel | 1 comments | | HN request time: 0.199s | source
1. YuukiRey ◴[] No.41846062[source]
We are using this at work. Generally I'm pretty happy with the configuration driven approach. You have config objects for all your collections where you define the types of the fields and everything else happens automatically.

With this comes a few gotchas. It's easy for an unassuming developer to change the name of a field (e.g., upper to lower case) and suddenly all data is gone in production since this affects the database. What you should do instead is write a migration.

I'm also not a fan of Lexical. It's very focused on being a good rich text editor but not on being a good document format for your clients. For example the way they render lists is, in my opinion, simply wrong (see https://github.com/facebook/lexical/issues/2951). Or this https://github.com/facebook/lexical/issues/6269. You also have the added complication of using the Payload flavor of Lexical, which can add its own complexities.

I haven't had time to look into its GraphQL API yet.

Documentation wise I'd compare it to working with NixOS. For some simple tasks the documentation is useful but for anything more complicated you want to look at the Payload source code. Especially when you start customizing the UI. Which generally works pretty well.

I wish they had thought about versioning the Rich Text somehow, so a client knows which version of your documents they get.

Overall I like it.