-
Notifications
You must be signed in to change notification settings - Fork 0
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
create table technical design #71
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's also have Allie take a look at this tomorrow with us. We can keep commenting on the code and have discussions over spec. Let's see what we do and do not like about this process in general too. At the end of the month we can set up a meeting to discuss if we think we have an idea on what our official process for spec or tech design review and approvals should look like.
|
||
The data types this table can handle are the following: | ||
|
||
For display puposes: `boolean`, `date`, `image`, `link`, `number`, `string` and `render`. The `render` type being a custom JSX. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should figure out how to identify which of these is part of MVP and which is future.
Also, we need to figure out what these little guys are called. They will be used in a reusable manner all over Cascara. Basically they are like display atoms or something. And they will have an editing experience as well.
- Maybe we just call these guys "atoms". And for all atoms they have an editing or display presentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, atoms
is a more descriptive term.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brianespinosa, I double-checked the apps to see which atoms are to be included in the MVP.
The lists are the following:
Display
- boolean
- date
- link
- number
- string
Edit
- switch
- input
- datetime picker
- select
- lookup select
The atoms we use fordisplay
will be different to the atoms we use for edit
, that doubles the effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For "edit" the experience needs to be more simple for MVP. I think for boolean we can only do a default html checkbox. For date, we should show an input date time field, not our own date picker. Basically the edit experience for MVP is going to be: whatever is available in html and what do browser vendors provide natively. We will absolutely have other options though in the future:
- switch versus checkbox for booleans
- custom date picker to be consistent across all browsers (except I think keeping native pickers on mobile)
- custom select/dropwdown component of our own so we can control the UI/UX (again I think the exception would be mobile)
- lots of others
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sounds good! Thanks for reminding me about HTML5, the mobile functionality aspect is very important.
I mentioned the switch instead of checkbox because wee have tables that implement it. At the end of the day we can style an HTML5 checkbox to make it look/behave as a switch. I have some ideas on that matter that I want to explore and run by @CaffeinatedAllie.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. I think with these atoms, there are also use cases where we will want a checkbox too. Eventually someone could decide which control they want to show for their boolean. Does a checkbox, a switch, an enum select make the most sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, they completely make sense. The enum select will have the true
, false
values - we could also allow the user to set the labels to support localizaton.
You just uncovered a track we can start to follow in terms of abstraction, looking forward to it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will start typing these ideas into code soon, these kind of convos make really think about implementation! 🙌
|
||
## Context | ||
|
||
All the internal logic will be hosted in a Context. The definition is WIP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I can tell this is specific to React context. 👍🏽 Moving forward, any time we are referring to something that is part of React as part of the API, or any other tool as part of the API, we should figure out a consistent way of calling that out. We have a lot of terms in our ecosystem that have special meaning which we want to be clear on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup, that's React Context. I will make it clear throught the document.
thanks! Co-authored-by: Brian Espinosa <brianespinosa@users.noreply.github.com>
thanks! Co-authored-by: Brian Espinosa <brianespinosa@users.noreply.github.com>
@@ -142,3 +142,34 @@ For mutation purposes, the implementation will support `select`, `input`, `boole | |||
## Context | |||
|
|||
All the internal logic will be hosted in a Context. The definition is WIP. | |||
|
|||
 | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha holy crap. That is a lot. This is going to make it difficult to work with our files if we have to jump over big data IDs. I wonder if there is a way to define these big chunks of data as reusable links at the foot of a MDX file. That way if we DO want to do this and not just place a file relative to the file itself, the big chunks of base64 are at the bottom of the document.
- Not sure if reusable links will work with base64 images but could we try it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nahh, it didn't work 😞
but, we now have svg diagrams!
Updated with develop. As soon as checks pass again, will merge. Thank you @lordpixel |
|
||
// We need to make sure this is only actual files and not a directory | ||
// so we are filtering it to make sure the size of the file is not zero. | ||
const mdxDirFiles = mdxDir.filter((file) => file.size > 0 && file); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to make sure we are trying to parse MDX for actual MDX files and not a directory.
This is a draft of the technical design for Table.
It's still in progress but I think it's good enough to start the discussion.