Hi @nikolovlazar, Appreciate your hard work. Can you share your github repository of this project so we can have the overview of the whole project?
Unfortunately I can't watch the streams live to interact in real time. I'm at minute 12:21 when you explain you removed the DTO and instead ypou return the data subscribed to a specific return type to avoid leaking sensitive info. But in that case youcould still access the rest of the data it only won't suggest in in the intellisense and obviously will say propery doesn't exist but at runtime it will actually show, right? Would it not be more secure to create a CollectionOutputSchema with zod and pass the data (whole data object) to CollectionOutputSchema.parse(data)? that way, when you return the data in the service it will only contain the fields from the schema, the rest will be stripped away i believe, that way you really make sure they won't react the client and you get to do validation like it was the DTO. Sorry to always spam the comments lol :c
Re: null/undefined for `description` – I think it's always better to stick to `null` and never use `undefined` unless forced to. There are many issues with `undefined`, especially when serializing/deserializing it via `JSON.stringify`/`JSON.parse`. I don't think it's much of a problem that frontend now needs to use `null` instead of `undefined`, since frontend depends on backend and backend's API (based on server actions) uses `null`. I think it's better to duplicate Zod schema and adjust it for frontend's form library rather that propagate `undefined` beyond where forced to.
@nikolovlazar