#bookbrainz

Hi akashgp09 ! I did start something but then promptly forgot, sorry about that. Let me get right on it.

cool np😇 thank you :)

akashgp09: This is the type of component I had in mind: https://usercontent.irccloud-cdn.com/file/RQcIT...

A new component separate from the relationship editor, where the user can search for entities to add to the series (and modify the positioning and numbering) straight on the page.

In the background, it will still work with relationships, so there's some extra logic that will be needed to concatenate the relationships from that component and the ones from the relationship editor, but that shouldn't be tricky.

What are your thoughts?

this looks great.

I have some questions.

The series items as well as the relationships will be stored in the relationship table right ?

Correct

So when we fetch the results from the relationship table

We're using the relationships as they are now to convey all this information, we're just presenting it certain relationships ("x part of series") in a separate component

on what parameter we can differentiate the series items and other relationship ?

Indeed we'll have to filter which relationships we send to the new component and which ones we send to the relationship editor

> We're using the relationships as they are now to convey all this information, we're just presenting it certain relationships ("x part of series") in a separate component

ooh got it

We already do this for other relationship, for example presenting the Works of an Author in a separate table

"x part of series" can differentiate that

Correct

Let me find an example

Here's one: https://github.com/bookbrainz/bookbrainz-site/b...

(I tihnk)

Yes it would be similar to this

This is currently used for displaying only, so it's a bit simpler. For example there's no Redux state to modify

But I think this is all achievable. It will move some of the complexity that was added to the relationships section (for example the drag-and-drop sorting) to another component, which is probably a good thing.

And as far as UI goes, I think this is easier to understand and interact with compared to using the rel editor.

Let me know if you think this is achievable within our timeframe, if we should keep it for very last (after all we do have a working feature in the rel editor), or even just make it a ticket for the future

> For example there's no Redux state to modify

i didn't understand this. can you elaborate a bit more

Right. The code example I sent only deals with displaying the entity, and not with the editing part

In the editing part it's currently all just done with the relationship editor.

yea but incase of series that would be different because we will not be using the rel editor any more

In these modifications I'm suggesting for the editing page, we'll need to have some logic somewhere to separate the relationships between the rel editor component and this new "series parts" component.

I think we might want to also keep the relationship editor, as there may be other types of relationships for series other than "x is part of series" in the future

So for example when editing an existing series, we'll get an array of relationships. We select the "x is part of series" relationships and use that in the "series parts" component's redux state, and the rest of the relationships are used in the relationship editor's redux state.

At the end when saving the changes, we reassemble these two separate redux states into a relationship array.

Does that make sense?

Yes now it's very clear

I can achieve this within our timeframe.

The reassembling part will be done in the `transformNewForm` functions in src/server/routes/entity/series.js

We'll have the original `relationshipSection` and a new redux state section for the new component. The relationship sorting based on `seriesOrderingType.label` can then be done on the new component relationships only.

yeah sounds great 👍

Great :) Don't hesitate if you need a hand !

should we revert the relationship editor to it's previous state ?

I'll get a cleaned up example fo the html markup I used for the mockup

I need to look closer at the relationship editor. I think some part should be reverted (i.e drag n' drop ordering), but some parts will be useful in the future (i.e. the ability to show a relationship's attributes - we were showing the 'position' attribute which we probably won't need to anymore, but we'll want to show the date attributes there in the future)

i will remove this case https://github.com/bookbrainz/bookbrainz-site/b...

then it will not show the number attribute in the rel editor

Right, that looks right.

But indeed we keep the rest of the logic for showing attributes 👌

yes the relationship atrribute component will fit well for displaying future attributes

we will just need to add the case for it in the switch statement

Exactly.

Cool. I will start working on it from tomorrow. Thank you, monkey for the mockup and the detailed explanation.

:)

👍 Don't hesitate if you have questions !

All this I should have done during the proposal period, or at the very beginning, sorry about that !

not a problem. we have plenty of time :)

Here's the markup I used for the mockup, cleaned up and commented a bit:

In case it helps.

It wasn't perfect, but it might be a good base

okay thanks.