Skip to content

Form layout#1054

Merged
pngwn merged 9 commits into
mainfrom
form-layout
Apr 22, 2022
Merged

Form layout#1054
pngwn merged 9 commits into
mainfrom
form-layout

Conversation

@pngwn
Copy link
Copy Markdown
Member

@pngwn pngwn commented Apr 21, 2022

Implements form groupings when there is more than 1 adjacent form. Part of #1041.

Run demo/fake_gan_complex to see this in action in a complex flow of components (with multiple foprms groups of different sizes).
Run demo/kitchen_sink to see all forms together.

@gary149 Few implementation notes here. I added a new class to the components layer of tailwind to apply the new spacing. We had to switch to margins instead of gap because you can't switch off gap for certain elements. The lobotomised owl selector is pretty standard for child component spacing though and gives us the flexibility we need. Let me know what you think.

We do have some styling in the global css and some in the components themselves but since those styles are applied to components directly we still remain in complete control, so I think it should be ok.

Screenshots

Screenshot 2022-04-21 at 12 30 46

Screenshot 2022-04-21 at 12 46 27

@pngwn pngwn requested a review from gary149 April 21, 2022 11:44
Comment thread ui/packages/app/src/Render.svelte Outdated
Comment thread ui/packages/form/src/CheckboxGroup.svelte
Comment thread ui/packages/form/src/Dropdown.svelte
Comment thread ui/packages/theme/src/global.css
Comment thread ui/packages/atoms/src/Block.svelte Outdated
Comment thread ui/packages/theme/src/global.css Outdated
Comment thread ui/packages/theme/src/global.css
Comment thread ui/packages/theme/src/global.css
@pngwn pngwn mentioned this pull request Apr 21, 2022
31 tasks
@abidlabs
Copy link
Copy Markdown
Member

abidlabs commented Apr 21, 2022

Wowow the screenshots (especially the second one) look so nice!

@pngwn what do you think about a dedicated gr.Section([component1, component2...]) that takes in a list of components for the use case shown in the 2nd screenshot? For 2 reasons:

  • Using a standard Markdown component is actually not ideal for users since now the value of that Markdown element gets passed as one of the parameters of the function. (In the case of this mock function, it doesn't matter, but it would matter for real functions)
  • We could make sections collapsible, which would lead to really nice UI especially when there are a lot of options (see Implementation of a collapsible accordion (for advanced options for e.g.) #938)

Beyond the scope of this PR, but we can create an issue around it.

@gary149 gary149 self-requested a review April 21, 2022 18:10
@pngwn pngwn merged commit 0cecff4 into main Apr 22, 2022
@pngwn pngwn deleted the form-layout branch April 22, 2022 09:20
@pngwn
Copy link
Copy Markdown
Member Author

pngwn commented Apr 22, 2022

@abidlabs I think it would be good to have a conversation around the narrative for interface + blocks and where those boundaries like. We could say to users that for layouts like this then they should move to blocks. That said I think your proposed 'section' component would be really nice. It could take a title, aribtrary (and optional) markdown and a list of components. It could be collapsible, configurable via a flag.

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 this pull request may close these issues.

3 participants