Even though React's useReducer has gained a lot of popularity during the last couple of years, it can be difficult to use for some common cases. Specifically, it requires a lot of boilerplate to support async actions.

Have you ever had the daunting task of checking whether developers coded a component (e.g., button, checkbox, alert) according to spec and needed to find ALL instances of that component in a huge collection of pages in an unfamiliar design system? Let’s say you have a spec for an alert banner (component/symbol). You know what it’s supposed to look like. But now, you need to find every single page or modal that alert appears on, how to navigate to it, and what conditions cause it to appear, so you can check that all instances are coded to spec. Gulp! You definitely don’t want to open file after file of page-level specs/comps, search multiple pages and artboards, in a slow tedious hunt for that elusive little component, especially if there are 100+ files and hundreds of artboards in your design system. This is the dilemma I faced on a recent project. 

Declarative code: it’s a hot term in all types of programming. But what does it really mean? More importantly, how do you make the jump from understanding the concept to actually writing declarative code in your projects? 

Application + style guide = smart buy

A recent project called for the creation of a single page site that would showcase a real estate agent’s expertise, sales history, professional connections, and various other impressive attributes. Pages would be generated using a fill-in-the-blank template. Eventually, two additional real estate agencies affiliated with our client would make their own versions of the page, identical in function, but with slight changes in styling and content. Future brand-specific styling variations would need to be documented somewhere, so Bitovi offered to provide a fill-in-the-blank re-usable style guide to go along with the template page. Both the template and the style guide could be cloned and restyled as many times as desired. Hence, our client bought themselves a cookie cutter vs. paying for one cookie at a time.