Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edge browser: show edit component based on the invitation spec #374

Closed
melisabok opened this issue Feb 19, 2021 · 7 comments · Fixed by #399
Closed

Edge browser: show edit component based on the invitation spec #374

melisabok opened this issue Feb 19, 2021 · 7 comments · Fixed by #399
Assignees

Comments

@melisabok
Copy link
Member

melisabok commented Feb 19, 2021

Remove the code:

    switch (editInvitation.name) {
      case 'Paper Assignment':
        editEdgeWidget = (
          <EditEdgeToggle
            isAssigned={metadata.isAssigned}
            addEdge={addEdge}
            removeEdge={removeEdge}
          />
        )
        editEdgeWidgetPosition = 1
        break

      case 'Recommendation':
        editEdgeWidget = (
          <EditEdgeDropdown
            label={editInvitation.name}
            isAssigned={metadata.isAssigned}
            options={editInvitation.weight['value-dropdown']}
            selected={editEdge.weight}
            default=" "
            addEdge={addEdge}
            removeEdge={removeEdge}
          />
        )
        editEdgeWidgetPosition = 2
        break

      default:
        break
    }

and create the component based on the invitation weight or label spec.

If value-dropdown then use EditEdgeDropdown
If value-radio then implement a widget to render the options as buttons(?) or use a dropdown too.
default should be EditEdgeToggle

@xkopenreview
Copy link
Collaborator

it looks like content.label from the edit invitation is not used at all

@melisabok
Copy link
Member Author

If the edit invitation is like the Bid Invitation, then we should read the label.

@xkopenreview
Copy link
Collaborator

xkopenreview commented Feb 25, 2021

the main purpose for now is to support 3 kinds of edit invitations:

  1. Bid - may have label with type value-radio in invitation
  2. Recommendation - may have weight with value-dropdown in invitation
  3. Paper_Assignments - may have label with value-regex or weight with value-regex or label+weight with value-regex

the logic to decide the control to render is:

  Label only Weight only Label+Weight None
value-radio EditEdgeDropdown EditEdgeDropdown EditEdgeDropdown 2x EditEdgeToggle
value-dropdown EditEdgeDropdown EditEdgeDropdown EditEdgeDropdown 2x EditEdgeToggle
value-regex EditEdgeToggle EditEdgeToggle EditEdgeToggle EditEdgeToggle
may expand later TBD TBD TBD TBD

when an EditEdgeToggle is rendered, the label text following the editEdge param in URL should be the label when creating a new edge.

if the invitation has only label field and specified value-regex, check if the url has the label, if not ui should render an input to collect label from user. if url has label, it should be used to the label in new edge created.

@xkopenreview
Copy link
Collaborator

let's say we are rendering a dropdown for label and a dropdown for weight and the edit invitation in URL has specified label:some label.

when adding an edit edge, should the label be fixed to the label in url or allow selection of label?

@melisabok
Copy link
Member Author

If the label is present in the url then I wouldn’t render the widget and use that value to post all the edges.

@zbialecki
Copy link
Contributor

Changes we discussed on today's call:

  • support multiple edit edges from 1 invitation
  • support multiple edit invitations
  • support traverse and edit invitations being different

@xkopenreview
Copy link
Collaborator

I think i will split the editEdge to two properties:
1: editEdges - existing edges that can be deleted or modified(has id)
2: editEdgeTemplate - the edge created from edit invitation (has no id)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants