bitmap: does passing `{children}` not work with hydration?
2025-10-24 29707, 2025
reosarevok[m]
(I'm trying to pass display-only children to a hydrated form where all the important bits would otherwise be shared, but I'm getting errors when it tries to hydrate:)
2025-10-24 29709, 2025
reosarevok[m]
Uncaught Error: Objects are not valid as a React child (found: object with keys {key, ref, props, _owner, _store}). If you meant to render a collection of children, use an array instead.
2025-10-24 29729, 2025
reosarevok[m]
Not sure if I'm doing something dumb or the whole thing just won't work because of how hydration works :)
2025-10-24 29744, 2025
SothoTalKer has quit
2025-10-24 29709, 2025
SothoTalKer joined the channel
2025-10-24 29732, 2025
Sophist-UK joined the channel
2025-10-24 29712, 2025
pite joined the channel
2025-10-24 29721, 2025
pite_ has quit
2025-10-24 29708, 2025
aerozol[m]
monkey: maybe better to do a side discussion re. design? Because timezones will be tricky. Maybe the design discussion before you all meet? I have a few ideas to simplify and would be happy to supply a draft next week, to discuss
2025-10-24 29731, 2025
aerozol[m]
(for YiM)
2025-10-24 29709, 2025
bitmap[m]
reosarevok: not exactly, but if you're passing the children on the server, it's not going to work with the way MB implements `hydrate` specifically
2025-10-24 29734, 2025
bitmap[m]
the react elements use symbols IIRC so can't be converted to/from JSON
2025-10-24 29750, 2025
bitmap[m]
once we merge the react 19 changes I can look more into the new server rendering APIs
2025-10-24 29754, 2025
reosarevok[m]
I see
2025-10-24 29758, 2025
reosarevok[m]
I was hoping for something like
2025-10-24 29759, 2025
reosarevok[m] sent a code block: https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/NfBWxflvUDdpARFLOSRhdcrZ
2025-10-24 29719, 2025
reosarevok[m]
Then going into something like
2025-10-24 29720, 2025
reosarevok[m]
<form method="post">... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/YjHwzQIXyLFSqiFHPrUPclKP>)
2025-10-24 29748, 2025
reosarevok[m]
I guess I could store both options on the form itself and pass a string to determine which one to use (plus the extra params needed for display by the other option)
2025-10-24 29738, 2025
reosarevok[m]
Or we could wait with this PR until the React 19 changes are merged if you think that'll make it simpler
2025-10-24 29700, 2025
monkey[m]
<aerozol[m]> "monkey: maybe better to do a..." <- Let's do that! Chat sometime next week?
2025-10-24 29718, 2025
Maxr1998 has quit
2025-10-24 29736, 2025
Maxr1998 joined the channel
2025-10-24 29717, 2025
monkey[m]
<ansh[m]> "> <@monkey:chatbrainz.org..." <- I am thinking we should get started sooner than later. If we have other stuff to discuss maybe that makes it this month's meeting in advance? (Considering we skipped the last one it's justifiable)
reosarevok: I would avoid a shared `EditArtistCreditForm` for now. you can can split them and have a shared component for the AC/edit note fields\
2025-10-24 29753, 2025
reosarevok[m]
bitmap: would that involve only hydrating that inner component?
2025-10-24 29710, 2025
Sophist_UK joined the channel
2025-10-24 29725, 2025
bitmap[m]
well I didn't look at the PR too closely but is there a reason the entire split form needs to be hydrated, or is the AC editor the only interactive component?
2025-10-24 29731, 2025
Sophist-UK has quit
2025-10-24 29754, 2025
aerozol[m]
monkey: How about meeting my Friday morning/when we've done it in the past?
2025-10-24 29732, 2025
reosarevok[m]
bitmap: only the AC editor rn. We might want to also hydrate the edit note to detect invalid ones, but that's a wider thing we could do later
2025-10-24 29704, 2025
monkey[m]
aerozol[m]: Yes this coming week that works fine for me 👍️
2025-10-24 29737, 2025
reosarevok[m]
bitmap: I'm not even sure we *need* the doc bits to be inside the `<form>` to begin with tbh
2025-10-24 29700, 2025
reosarevok[m]
We could just try and take them out and still have the Form component be a form
2025-10-24 29720, 2025
bitmap[m]
I think if you split the components you could keep it mostly the same, by having a shared (server) component for both forms to call
2025-10-24 29752, 2025
bitmap[m]
it's just that the doc parts have to be inside the components
2025-10-24 29716, 2025
reosarevok[m]
Yeah, that seems doable, will check
2025-10-24 29730, 2025
aerozol[m]
I know it's a bit annoying monkey but how would your 8pm be?
I'm testing the recording edit form again and looking into the error display stuff. I guess we don't implement client-side errors for the AC editor at all right now, so seeing how easy it would be to implement that
2025-10-24 29731, 2025
reosarevok[m]
Sounds good!
2025-10-24 29738, 2025
op3kay[m] joined the channel
2025-10-24 29738, 2025
op3kay[m]
hey i noticed that the default user in the local setup isnt email verified so we would have to manually update the DB to test verified user flows. would it make sense to have an alt user as well who is verified by default so both user flows could be tested ?
2025-10-24 29710, 2025
monkey[m]
<rayyan_seliya[m]> "Hey monkey: would love to know..." <- I did miss the message, thanks for the nudge. Basically, until we have a way to upload covers to a Book Cover Archive (like MB does with the Cover Art Archive, that's a very big and complicated project), we could show books covers for those Edition entities that have an OpenLibrary identifier or an ISBN, using their covers API: https://openlibrary.org/dev/docs/api/covers
2025-10-24 29755, 2025
monkey[m]
> The URL pattern to access book covers is:... (full message at <https://matrix.chatbrainz.org/_matrix/media/v3/download/chatbrainz.org/eBOwycjNJlwTijLBzukhHubI>)
2025-10-24 29741, 2025
rayyan_seliya[m]
Thanks for the info monke y: that openlibrary api reference..using it for editions with openlibrary id or isbns sounds great solution.. so is it worth it to research on this like how i can help in this any recommendations ?
2025-10-24 29710, 2025
monkey[m]
<rayyan_seliya[m]> "Thanks for the info monke y..." <- I think it would make a nice self-contained improvement PR, and doesn't require a lot of knowledge of the codebase. A nice entry into the project if you want to give it a try :)
monkey[m]: Thx for this will ping u if any doubts..!!
2025-10-24 29755, 2025
bitmap[m]
op3kay: hi, which default user are you referring to?
2025-10-24 29716, 2025
bitmap[m]
assuming you are talking about musicbrainz-server
2025-10-24 29708, 2025
op3kay[m]
about user mb
2025-10-24 29703, 2025
bitmap[m]
op3kay: we don't set up any default user named 'mb', so not sure what that is. are you using the sample database dumps? it's true that we don't set accounts as verified in the sample dump, and that would indeed be useful
2025-10-24 29756, 2025
op3kay[m]
my bad i meant the sample database dump
2025-10-24 29700, 2025
reosarevok[m]
IIRC with the sample dump locally you can use our admin tool to override verification at least (from /admin/user/edit/username)
2025-10-24 29727, 2025
bitmap[m]
setting placeholder emails on the editors would definitely be useful though IMO, it's been requested in the past (or at least I've had to explain how to set emails before)
2025-10-24 29748, 2025
bitmap[m]
op3kay: if that's something you want to work on I can give you pointers
2025-10-24 29746, 2025
op3kay[m]
yea id like to work on that
2025-10-24 29703, 2025
reosarevok[m]
That reminds me a bit of MBS-13390 which I guess we only half-fixed really
I mean, UPDATE editor SET email = 'example@example.com' WHERE email = ''; is kinda a fix? :D but it should at least probably happen on dump generation for samples / on DB import for test
2025-10-24 29707, 2025
op3kay[m]
BrainzBot: Yes! this is the exact issue i was facing.
