Working with globalized variables maybe one of the trickier aspects to any design or code project. It’s sort of like accumulating a collection of a particular collectable, say Pokemon cards. It’s cool that you can collect these cards! I mean, who wouldn’t want an original 1st edition base set Charizard. As your collection grows, without some sort of organization system, say a binder, it may become difficult to find cards you want. The same can be said about variables. It’s not enough to support it as a feature. You also have to encourage or provide a framework for maintaining them.
Component libraries, frameworks, and toolkits share a common goal. That goal is to provide users with the ability to do cool things with less work. G2 Components is no different in that regard!
They can provide power by focusing and abstracting away complexity (like MATH!). They can provide UI cohesion by building upon and encouraging specific usage patterns. They can also provide safety nets by understanding multiple use cases and supporting those use cases with sensible defaults.
One of the biggest challenges (if not the biggest) is to do all of this while being as flexible as possible. As far as React UI is concerned, I can’t think of another pattern that does this better than the humble “as” prop.
In this zoom session, we explore horizontal and vertical alignment patterns and create highly composable and reusable CSS components – Flex, HStack, and VStack.
HStack and VStack have become a core foundation within the G2 Components project.
Source code from this session can be found here: https://github.com/itsjonq/hstack-vstack-css
It’s been a little quiet on this blog. Rest assured, a lot of interesting and important work is being done within G2! The two major updates include adding support for inline documentation (for supported editors) as well as a bunch of performance optimizations. Both of which are in service of making G2 Components easier to use.
One of the more “abstract” but important and powerful systems within G2 Components is it’s “Context” system. Given the name, those familiar with libraries like React may immediately think of
React.Context. It’s kinda close, but it’s much much more than that.
The goal of G2’s Context system is to provide “awareness” to the components. Components that are “connected” to this system can become “aware” of each other, and can modify their behaviours depending on how they’re composed together. A simple example would be how a
MenuItem may automatically render a right chevron icon when it is used within a link, because it knows that it should render as link.
One of the biggest and most important challenges for the G2 Components project was defining and creating the Style system. The Style system is one of the core system that’s responsible for managing and powering the entire UI layer for the library. G2’s styles had a handful of truly unique requirements – Features that are often only subtly addressed or even omitted from existing solutions. For this post, I hope to touch upon some of the important mechanics and considerations for the G2 Style system (without drilling down into the possibly boring nitty gritty details).
Drag gestures are becoming increasingly more popular in Web UIs – and for good reason! They’re super easy to use! They extend the fluid “life-like” experience we’ve become accustomed to from the mobile/tablet world. Therefore, it’s important that this library includes a solid and flexible drag / drop / sort system.
The funny thing is… Drag/Sort systems are almost always excluded from Component libraries. The main reason is… well… because they’re heavy and complicated (aka. really hard!). I believe taking on this complexity is worth it as we’ll be able to provide users with an easy to use + powerful way to create highly interactive experiences – be that in Gutenberg’s UI, custom Block controls, WP Admin, and beyond.
For years now, I’ve been thinking very deeply about design systems, with a focus on UI / component libraries. Based on my experience, I believe that a lot of the UI related pain felt by designers, developers, and other contributors, are due to an underdevelopment or even an absence of very important and often under-estimated core UI systems.
Given the context of Gutenberg and the web, it is worth pointing out that working on an application/platform is very different compared to working on a website. The underlying web technologies may be the same (HTML, CSS, JS). The difference is how these technologies come together, especially considering factors like scale (how many people work on it) and longevity (backwards compatibility + legacy support). One way of looking at it is…You probably wouldn’t build, say, Mac OS the same way you would build a restaurant landing page.
With that being said, the goal of this experimental component library (or any component library) isn’t to craft the most elegantly engineered system-obsessed chunk of code. Far from!
These core systems should feel invisible to folks using the library – kind of like an automatic transmission for a car. They exist for the primary goal of providing the best user experience possible – allowing users to do more with less.