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

Tables: constrained and highly customizable collections #37

Open
joepio opened this issue Jun 3, 2021 · 0 comments
Open

Tables: constrained and highly customizable collections #37

joepio opened this issue Jun 3, 2021 · 0 comments

Comments

@joepio
Copy link
Member

joepio commented Jun 3, 2021

Tools like Airtable and Notion have re-defined how we think about tables. With these tools, users can:

  • Change the columns and set custom properties with constrained datatypes
  • Configure sorting / filter / view types, and share these views
  • Easily create / instantiate / edit data from within this view

In Atomic Data, we already have Collections that can be shown in a Table component (in Atomic Data Browser). However, Tables could offer some extra features:

  • Constrain Classes. All children need to be instances of some particular Class. This prevents setting the Class as a child, though. We could also only constrain members instead of children.
  • Support a regular-old JSON (without long HTTP urls) REST API that accepts POSTing to /new or something. Because we have Class constraints, we don't need to use long URLs in properties. Also, we could scope tokens / authorization to this collection, and remove the need for Commits.
  • Custom Views. A view contains information about filter / sort / displayed properties. This is what airtable and notion do.
  • Hierarchy guarantees. Queries always are the parents of their children, contrary to Collections which often just query over existing items. Maybe this means it always filters data in some particular way.

More thoughts:

  • Collections seems to insinuate some form of ownership, so maybe these should be renamed to Queries (thanks @Polleps)
  • If you create a table and edit its columns, are you in fact editing a Class? I'd assume so. And is this Class a child of the Table? This would not work if you constrain the children of a table.

So, how to achieve this?

Extend the existing Collection class

The Collection Class already allows for filtering by property / value, sorting on any property.
Maybe adding fields for view (e.g. grid, or some custom thing) makes sense?

But how should we indicate that it filters by parent? We could introduce a parent filter, which is an optional resource that performs a filter in the Query.

Adding a new Table class

The Table:

  • class the required class, containing the required and recommended properties
  • view the default view (e.g. table / grid / list). Maybe we also have a list of availableViews
  • members the list of child resources. We could only show items here that are both children as well as fitting the shape of the table.
  • newendpoint that allows posting a new resource to this table.

The View:

  • properties order or properties shown in header (question: how does this relate to properties in the class? Must they be the same? What if there are more properties in the Table, does that mean these are required?)
  • sort, filter, pagination... all the collection stuff

Authorization / rights and appending

Let's say I want to add a new or an existing item to a table, such as a Comment to some ChatBox. How do I do this?

We probably don't just want to determine who can read and edit tables, but also who can add items to it. I think we'll need a new right. #96

We could set the parent of the Comment to the ChatBox's Table.
No extra properties required, because parent is always required. Seems clean!

But what if you don't want the one controlling the Table to control all its items? For example, if you start a Thread you might not want to give the creator of the thread edit rights to all resources.
Should we allow users

@joepio joepio changed the title Tables / constrained and highly customizable collections Tables: constrained and highly customizable collections Jun 30, 2021
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

No branches or pull requests

1 participant