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?
akashgp09
this looks great.
I have some questions.
The series items as well as the relationships will be stored in the relationship table right ?
monkey
Correct
akashgp09
So when we fetch the results from the relationship table
monkey
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
akashgp09
on what parameter we can differentiate the series items and other relationship ?
monkey
Indeed we'll have to filter which relationships we send to the new component and which ones we send to the relationship editor
akashgp09
> 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
monkey
We already do this for other relationship, for example presenting the Works of an Author in a separate table
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
akashgp09
> For example there's no Redux state to modify
i didn't understand this. can you elaborate a bit more
monkey
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.
akashgp09
yea but incase of series that would be different because we will not be using the rel editor any more
monkey
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?
akashgp09
Yes now it's very clear
I can achieve this within our timeframe.
monkey
The reassembling part will be done in the `transformNewForm` functions in src/server/routes/entity/series.js
And separating the relationships between the rel editor and the new component should be in `seriesToFormState` in the same file
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.
akashgp09
yeah sounds great 👍
monkey
Great :) Don't hesitate if you need a hand !
akashgp09
should we revert the relationship editor to it's previous state ?
monkey
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)