Fix/111895 event venue separation logic presentation

[paulmskim]

For ticket: https://central.tri.be/issues/111895

[mitogh]

Just a minor adjustment on a props call.

[mitogh]

Would be ideal to add in expand on this comment a bit on what's specific set of logic the comment is referring.

[paulmskim]

This is a general comment for all maybe functions, the logic in each one differs. In this case, it's the maybeRemoveEntry() function which has checks for empty details. We should be doing this check outside the function instead (or simply check for venue id as the id and details should exist together) and call removeEntry(). The maybe obscures the logic and makes the code difficult to follow.

I've created a ticket here for this: https://central.tri.be/issues/112316

[mitogh]

Oh! Great thanks for the heads up just wanted to make sure it's clear in case someone else works on this.

[mitogh]

You can call this on the container instead using the prop onBlockRemoved during the map of state to props.

Example:

• https://github.com/moderntribe/events-gutenberg/blob/master/src/modules/blocks/event-organizer/container.js#L73

[paulmskim]

This won't work either. As my comment says, the venue id persists from the saved state when the editor was first opened. You can replicated this by doing this:

• Create a new event or edit an existing event
• Add a venue block and add a venue or create a new venue.
• Save the event. Leave the page.
• Edit the event again. This time, the saved meta should populate the state through the setInitialState() function.
• Delete the venue block.
• Add another venue block. The old venue will populate the venue block automatically.

This happens because the saved meta still has the old venue id, and every time the venue block is created, the setInitialState() populates the block's initial state. Because the event was not saved after deleting the block, the database still has the venue id saved in the event meta. This is what populates the venue block again when creating a new one.

We need to deal with removing the setInitialState() function and treat the redux state as the single source of truth rather than fetching information from the database upon block creation.

I'd love to fix this in this ticket, but it's an entirely other issue in itself, so I've created a ticket to do some discovery into removing setInitialState(): https://central.tri.be/issues/112209

[mitogh]

I see, so maybe this one might be happening because of two reasons.

1. null is not consider as empty value when saving the attributes values so maybe we should use undefined (doesn't have to be on this ticket)
2. This might be related to this bug from core. Add hook for block deletion so post meta can be removed WordPress/gutenberg#5626 but can't say for sure.

[paulmskim]

removeVenue() sets the venue id to undefined already, not null. But either way, it shouldn't be grabbing a venue from a null id. Once the setInitialState() function is removed and the initial state is set properly, this problem shouldn't persist.