Cover photo by Lorenzo Herrera on Unsplash

I've never worked for Facebook, and React was released publicly in 2013, so obviously, my title is not 100% true. I have not been using React for 15 years. #clickbait

What I have been doing though is writing UIs basically the same way in a very repeatable process and with simple principles for 15 years. Same rules same process and I've used it for all kinds of web libraries and before I got my hands on Prototype and script.aculo.us even vanilla JS when we called it DHTML. Works with UIKit with Swift and Objective-C when building for iPhone and iPad too. The code I write to build a UI while it looks very different today goes through the same steps my code did 15 years ago when I got my first job as a web developer.

Screenshot of the website for script.aculo.us

1. Don't be dogmatic

Photo by Ross Findon on Unsplash

There's no need to be extreme about picking the absolute best way to do something. There's no perfect way to structure your folders and files. You can't pick the framework that will meet all your needs. What you can do is be pragmatic, make progress, and iterate.

If you need to get a demo of one screen ready to show the team then your choice of which library to use for network requests means nothing. Build the whole thing in a single file with whatever tools you have and know.

Learnt about why class components are dead in React and it's all about hooks now? Don't suddenly start converting files in the codebase 40 people commit to. Anything you learn other's need to learn too.

Rules and tradition can and should occasionally be ignored. One of the best times to do that is when you're doing something novel like one-off work, setting up a new service, etc. When you don't know the impacts of breaking the rules though it's best to follow the rules and traditions surrounding you. Most important is your team's rules and experience, then yours, then the immediate community (e.g. React) followed by the larger community (JavaScript).

Really this applies to more than UI programming but it's my most important rule.

2. Look at your design and focus on layout and behaviour

Photo by Scott Webb on Unsplash

Whether it's a sketch on a back of a napkin or a fully detailed high fidelity design there's two big things you should be focusing on first: layout and behaviour.

Because the vast majority of building a UI for a screen is drawing boxes and laying them out relative to each other. That is where so much of your impact is. You should always put effort into getting the colours, typography, and accents like borders and shadows correct but they come after.

Make sure to find all the margin's (space between boxes) and padding (space between a box edge and content). Talk and sketch out breakpoints which normally aren't as simple as xl, l, m, s, xs or desktop, laptop, tablet, mobile. Discuss content order by finding out what is most important. Finally reaching over into the next topic of behaviour make sure to ask what are navigation elements or landmark elements.

After this session you should know:

1. What boxes are on the screen and the content in them
2. The margin and padding between the boxes
3. Any relative relationships between boxes (x pushes y out)
4. Breakpoints in the design where things don't work with sketches that show what to do
5. Content order, navigation elements, and landmark elements

Either in the same session or another one (I recommend one session) you should then discuss behaviour. This isn't as simple as when I click X it will make Y zoom around but should include many of the events that occur through the lifecycle of a UI.

1. Click and touch events both for elements and the screen (tap, click, pinch, scroll, etc.)
2. Keyboard events
3. Screen lifecycle events (enter/exit, load/unload)
4. ARIA considerations if you're building a custom component (do not add ARIA attributes to everything)
5. UI element lifecycle events (enter/exit screen or viewport, load/unload, etc.)
6. Device events (rotation, low power, dark mode, low motion)

3. Outside in - big brush strokes first

From Halsey on Giphy

When you watch a lot of painters you'll see them lay down these big broad colours in large strokes to layout their painting then they refine and refine until they've got their new artwork. It can be really exciting and tempting to dive right into those tiny details that might mean a new challenge but it can be just as big a win to get 4 boxes on-screen laid out correctly.

If you've got a completely new app you'll be starting at the absolute top-level layout, new screen you'll start at the body of the screen and down, and if you've got a new section on a screen you'll be making space for that box and then filling it up. You should always start at the highest level of the layout you can and make your way down to the smaller details iteratively as you work down the layers and eventually into the most specific styling.

4. Fake it till you make it

Photo by Cookie the Pom on Unsplash

Don't connect real data right away. In some cases, this might be a rule to break if you're working with stable data that is already easy to access. In most cases, I've experienced it's best to just add in some hard-coded or mock data to start with, especially if you use tools like Storybooks where you can create example variations of the UI in different data conditions.

I find this also helps disconnect the UI from the way the data is actually sent, retrieved, and computed allowing for those parts to be better tested independently with unit tests and integration tests while the UI can then be tested using some kind of snapshot testing. You can then build your UI with a clear interface of how to send data in, respond to events, and handle event data.

That's all folks

If you enjoyed these ideas and wanted to talk more I offer career coaching, mentoring, and training for programmers, web or mobile, front or backend. Reach out to me on LinkedIn