Discussion | Declarative Design System

Story

As a DEVELOPER who IS WORKING ON A BOUNTY, I want to COMPOSE UI ELEMENTS MORE SEMANTICALLY so I can EXTEND WALLET FUNCTIONALITY WITH EASE.

The Semantic UI Design System excludes some nice-to-have “design primitives”… or maybe I just missing them.

Generally when designing an application’s frontend I’ve found it productive to include a declarative design system for constructing layouts. First, it increases speed at which new components, views and screens can be developed, plus developers can more easily standardize on a specific approach.

By declarative design system I am referring projects similar to Tailwind or the React specific Theme UI with shorthand variable props like alignCenter or mx3 used to extend core components layout components.

• https://tailwindcss.com/
• https://theme-ui.com/home/

Acceptance Criteria

• Flexible Design System

Any declarative design system would be helpful, whether it’s just plain’ol CSS or CSS-in-JS.

Unhappy Path

No declarative design system and increasing difficulty to maintaining the application as it expands in scope.

Assets

Started working on the BALANCER integration and found myself adding several CSS helpers due to my local development environment.

If maintainers are open to extending the primary CSS file, perhaps I can make a PR with minor updates or maybe even a subset of Tailwind, to more easily manage layout enhancements in relation to flex, grid and a few other spacing requirements.

Small Example

.flex {
    display: flex;
} 

.column {
    flex-direction: column;
}
.alignCenter {
    align-items: center;
}

.justifyCenter {
    justify-content: center;
}
.justifyStart {
    justify-content: flex-start;
}
.justifyEnd {
    justify-content: flex-end;
}
.spaceEvenly {
    justify-content: space-evenly;
}
.spaceBetween {
    justify-content: space-between;
}

[kamescg]

@corwinharrell Thanks for the context. That helps. Yeah… theme-ui definitely comes with a lot. And sorry for the confusion I wasn’t so much recommending that with the link and more-so just including some of the shorthand properties for a styled-components approach.

Honestly from a dev perspective I am perfectly happy with just Box and Flex as that’s what I end up using 95% of the time.

[heycorwin]

@Patrick1904 based off your recent comment about styled-components and moving away from Semantic, maybe we can just add a few layout components to manage layout requirements?

Something similar to https://styled-system.com/guides/build-a-box/?

Could add Box, Container, Flex and Grid to just handle the basics for now.

https://github.com/kamescg/horizin-apps/tree/master/packages/horizin/horizin-atoms/src

@kamescg @Patrick1904 I think this is probably the most light-weight option for now. Let’s take caution though when creating something like Box vs Container that we make sure it’s clear how each should be used. If there’s any ambiguity or potential overlap, perhaps we just opt for one over another. Box, Flex, and Grid may be enough.

@kamescg just to give you some context, over the last several months, we’ve been discussing options for starting in on NEAR’s own design system. @Patrick1904 and I have talked about lots of different options, and its likely that we’ll be sticking with styled-components, and then augmenting with something like styled-system to keep all of our design tokens / scales / our theme defined in one place. This is something that likely won’t happen extremely soon. I think Patrick would like to avoid something like Theme-UI for the time being, since it comes with emotion + mdx which are things we don’t need and we’d like to avoid installing dependencies we won’t use. He can weight in if I’ve miss-represented him in any way.