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

How would you model structure for a Kanban app? #225

Closed
bebraw opened this issue May 7, 2015 · 3 comments
Closed

How would you model structure for a Kanban app? #225

bebraw opened this issue May 7, 2015 · 3 comments
Labels

Comments

@bebraw
Copy link
Contributor

bebraw commented May 7, 2015

I am currently using a schema like this at my project:

{
  lanes: [{
    id: 'number', // has to be unique within lanes
    name: 'string',
    notes: [
      {
        id: 'number', // has to be unique within notes
        task: 'string',
      }
    ]
  }]
};

Especially dealing with id uniqueness is a little painful. The ids need to be unique because I need to deal with drag and drop (DnD) and it helps immensely with that.

To get a unique id for a new note I need to do something like this:

function getAmountOfNotes(lanesCursor) {
  return lanesCursor.get().map((lane) => lane.notes.length).reduce((a, b) => a + b) || 0;
}

The problem with nested structure is that besides this nasty check lookups across notes become difficult. That's something I need to do in DnD.

After some discussions it was proposed that the structure could be flattened like this:

lanesById: { // { laneId -> lane }
  1: { id: 1, name: 'Lane' },
  2: { id: 2, name: 'Other Lane' }
},
notesById: { // { noteId -> note }
  1: { id: 1, name: 'Note' },
  2: { id: 2, name: 'Other Note' },
  3: { id: 3, name: 'Yet Another Note' },
},
laneOrder: [2, 1], // [laneId*]
noteOrder: { // { laneId -> [noteId*] }
  1: [2, 1],
  2: [3]
}

This means we would effectively separate order from lanes and notes and flatten the structure. The benefit of this approach is that the lookups I need for DnD become very simple. On downside now we're dealing with id references.

I realized baobab facets could hide some of this detail. This way I could have notes and lanes at root level of the tree. To deal with lane specific notes I would implement a facet that takes lane id and returns notes to render (it would resolve the order based on above). DnD operations would operate on order through facets.

How would you resolve this with baobab? Does the facet approach sound sensible to you?

CC @christianalfoni

@christianalfoni
Copy link
Contributor

check answer on: survivejs/react-book#20

@bebraw
Copy link
Contributor Author

bebraw commented May 23, 2015

Thanks! Closing as it's probably better to keep discussion there.

@bebraw bebraw closed this as completed May 23, 2015
@Yomguithereal
Copy link
Owner

Will follow up there.

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

No branches or pull requests

3 participants