React Native Radio

RNR 188 - Styling with Style

Episode Summary

The panel talks about styling React Native apps -- styling frameworks, pros and cons, TypeScript integration, and more. Plus we get to hear what happened to Adhithi’s pop filter!

Episode Notes

The panel talks about styling React Native apps -- styling frameworks, pros and cons, TypeScript integration, and more. Plus we get to hear what happened to Adhithi’s pop filter!

 

This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.

Helpful Links: 

  1. Yoga: https://yogalayout.com/
  2. Yoga Playground: https://yogalayout.com/playground/
  3. RN Stylesheets: https://reactnative.dev/docs/stylesheet
  4. RN Styles: https://reactnative.dev/docs/style
  5. Getting Started with RN FlexboxLayout: https://programmingwithmosh.com/react-native/getting-started-with-react-native-flexbox-layout/
  6. BuilderX: https://builderx.io/
  7. FramerX: https://www.framer.com/

Connect With Us!

  1. React Native Radio: @ReactNativeRdio
  2. Adhithi - @adhithiravi
  3. Jamon - @jamonholmgren
  4. Robin - @robin_heinze

Episode Transcription

Todd Werth:

Welcome back to React Native Radio podcast. Brought to you by statically typed languages. What was old is new again. Episode 188, styling with style.

 

Jamon Holmgren:

Hey everyone. Welcome to the React Native radio podcast, where we explore React Native together. I'm your host, Jamon Holmgren, and I'm joined today by two of my three astounding co-hosts. Harris couldn't make it, but we do have Robin and Adhithi today. How's it going, Adhithi?

 

Adhithi Ravichandran:

Going very well. How are you Jamon?

 

Jamon Holmgren:

Going very well. The audience can't see this, but you don't have your pop filter in place right now. Apparently there was an incident this weekend or something.

 

Adhithi Ravichandran:

Yes. My daughter, she's a three and a half year old. She climbed the desk and unscrewed the pop filter, took it away, and I can't find the screws anymore. And she also climbed the refrigerator and fell from it. So it's been an interesting weekend.

 

Jamon Holmgren:

She survived the weekend-

 

Adhithi Ravichandran:

She did.

 

Jamon Holmgren:

-and so did you. So that's the important thing and Robin, how are you doing today? Your daughter didn't try to destroy your office did she?

 

Robin Heinze:

She did not try and destroy my office. She does routinely climb on the kitchen table though.

 

Jamon Holmgren:

I don't know who, it could have been one of my daughters, but someone cranked my volume all the way up last week. So on Friday, I was doing a meeting with the rest of the team for scheduling and turned on my mic and just blew everybody's ears out. So I had to go adjust everything on my mixing console here.

 

Robin Heinze:

Kids just they add a bit of entropy to our lives. 

 

Jamon Holmgren:

They do.

 

Robin Heinze:

Little chaos.

 

Jamon Holmgren:

Yeah. Well just rolling the dice a little bit here. I'm excited about our topic today, but before we do that, I want to mention that this episode is sponsored by Infinite Red. Infinite Red is a premier React Native design and development agency located fully remote in the USA and Canada. With years of React Native experience, since it was released and deep roots in the React Native community, we are the hosts of Chain React, which is the conference.

 

Jamon Holmgren:

And we also publish the React Native newsletter for over 12,000 subscribers. You can go check it out by the way, reactnativenewsletter.com. Infinite Red is the best choice in my humble opinion for your next React Native app. Hit us up infinite.red/reactnative. Don't forget to mention that you heard about us through the React Native Radio podcast. It makes all of this worth it. Appreciate it. Okay. Let's get into our topic for today. Today, we are talking about styling with style, all about React Native styling. I'm excited about this. I always enjoy these round table discussions that we have, but styling is something I'm not very good at. I'll be the first to admit, I am really more of a back-end engineer in a front-end world when it comes to this stuff. I love things like state management and moving data around and all of that. When it comes to making something look pretty, I always feel like I'm just pretending like I know what I'm doing and hammering on the keyboard.

 

Robin Heinze:

I have a bit of an opposite experience actually because I was a back-end engineer for a long time. And I thought I was terrible at front-end. I was like, "Oh, I'm not a front-end engineer." And then Jamon had me start learning, React Native-

 

Jamon Holmgren:

I like how it's always my fault that-

 

Robin Heinze:

-It is. It is.

 

Jamon Holmgren:

-this happened in your narrative. This is good.

 

Robin Heinze:

It's always going to be your fault. And I discovered that I actually really enjoyed styling my apps, and it was... I found it was immensely satisfying having the visual representation of the code I just wrote where like the screen changes every time I make a change, and it was really satisfying. And I actually found that maybe I was a front-end engineer all along.

 

Adhithi Ravichandran:

It's my experience too. I started off doing MFC C++ front-end stuff, and I hated it. So I was like, I hate front end. And then I got thrown into like a web project, and we used something I think like Knockout, GS. And I was like, "Hey, I like this." I can do stuff and see the changes pretty quickly and then jumped into React Native and started liking front-end for sure. I really like that whatever I do, I code, I see the changes in a second.

 

Robin Heinze:

I think maybe I thought I wasn't a front-end engineer because I really hated CSS. That's a spoiler, a foreshadowing for some of what we'll talk about today. But I really hated CSS and in React Native, you're not using CSS. And I found that I was able to really enjoy styling. So, sorry, web engineers.

 

Jamon Holmgren:

If it's okay. I'm going to go way back to the old days. Is that all right?

 

Adhithi Ravichandran:

That's okay.

 

Robin Heinze:

Insert audible groan here.

 

Jamon Holmgren:

Jamon's off to the old days again. When I first got into professional coding, I obviously did coding since I was 12, but the professional side of it really came in 2000, I guess 2004, I was doing... I built a website. I hadn't started my business yet. I started my business in 2005, but I built a website in 2004 for my church. Back in those days, I think it was already starting to change a little bit, but a lot of websites were still built using tables.

 

Jamon Holmgren:

They were laid out using tables. And so you would actually use a table element in HTML. You would use columns, and you could use things like call spans and row spans, I guess. And you could lay out your sections. Actually, I don't know if call spans and row spans were set up yet at that point. Anyway, it doesn't matter. The big thing was that we were using tables, which are not built for that. They're built for data, right? They're not built for, "Hey, put your navigation over here and Hey, put your... the main body of your website here and here's your header." But that's what I used it for. It was really simple. You just put your stuff where... It's like laying it out using Excel. You could literally design your website using Excel.

 

Robin Heinze:

Hey, don't knock on Excel. Excel could do a lot of stuff.

 

Jamon Holmgren:

It can do a lot of stuff. It's absolutely amazing. So that's what I did. And if I wanted a different color, I use inline styles. So I would say font equals Comic Sans, which was of course my favorite. Neither of you laughed. You just accepted that as if it was...

 

Robin Heinze:

It was so unsurprising.

 

Jamon Holmgren:

Oh, come on. That's how bad I am.

 

Robin Heinze:

To be fair at the beginning, you said that front-end isn't your thing.

 

Jamon Holmgren:

It's not.

 

Robin Heinze:

You're not into styling, so I wouldn't put it past you.

 

Jamon Holmgren:

Clearly. I did know now to use Comic Sans. I did not know not to use Papyrus and someone had to tell me that one.

 

Robin Heinze:

Oh my gosh.

 

Jamon Holmgren:

I'm sorry.

 

Robin Heinze:

Really? Papyrus Jamon?

 

Jamon Holmgren:

I built a website using Papyrus. I will admit it. Anyway, I then learned about CSS, and that you could make a style sheet and then you can put all of your styles in there. And then over the years, that's where all of the styles went. They went into styles.CSS. And that was like... You'd have a thousand, 2000 lines of CSS in one file and you'd load it on every page. And that of course isn't the greatest cause how do you know when you can delete a rule? You don't know where it's used. You don't know what's going on. And there were many other options, things that kind of came along. Systems. One of which was Bootstrap. Did you folks use Bootstrap at any point?

 

Robin Heinze:

I used Bootstrap. I used Bootstrap to build my very first websites that I ever made while I was at bootcamp. We had Bootstrap at bootcamp. Yeah. We used Bootstrap for all our stuff. I never built anything huge with it. So I never really understood a lot of the nitty gritty, but I could make buttons and rows.

 

Adhithi Ravichandran:

I've used Bootstrap too, several years ago at my first job, and we then moved away and created our own UI component library within the company. But it was just a copy of Bootstrap for the most part.

 

Jamon Holmgren:

I remember when Bootstrap came out and it was just mind blowing because that was not possible before that that I remember. There was just nothing as simple to use, and they made heavy use of CSS classes where you could just put in certain classes. But of course over time, the demands of the web became even more with responsive, building for responsive. I mean, I remember the very first time that I built a website, I just built it for 800 pixels because that fit every monitor that I could put it on. Fixed with 800. Table with equals 800, if everything had just stayed on 15 inch CRTs, everything would be great now.

 

Adhithi Ravichandran:

Those were the days.

 

Jamon Holmgren:

Unfortunately, these are different days. And so we are now into a different era. Now, when I started mobile, on the native side, it was... I remember the first time it actually felt like a step backwards when I was building views in RubyMotion/Objective-C because you would create a view, you would subclass a view.You'd be like, "Hey, here's my, I don't know, my header view." Okay. And it would just be named "Header View". And in your kind of initialization method, you would actually just assign properties like self set background color, UI color, blue color. I didn't say I was good at this stuff, but yeah. You'd actually just set properties directly like that. And it just be like one line after another. My background color is blue. My, my width is-

 

Adhithi Ravichandran:

800.

 

Jamon Holmgren:

-140 or 320. Actually I think 320 points was actually hard-coded a lot of times because that was the only smartphone there was was an iPhone and it was 320 points. Points were different than pixels. With a retina screen, it was like two pixels per point or something like that. And then it of course changed over time. And so there had to be new ways to manage that. Apple came out with auto layout. I think Android's layout system was actually superior for quite a while where it was just... It was probably closer to what we have today, but Apple had auto layout, which had some kind of funky ASCII art ways to lay things out. It is a really strange system-

 

Robin Heinze:

ASCII art?

 

Jamon Holmgren:

Literally ASCII art. You would put like... Almost like Markdown tables where you put pipes and dashes and stars and things like that.

 

Robin Heinze:

Oh gosh.

 

Jamon Holmgren:

It was really strange. There was also Struts and Springs, which you would mostly use in things like Interface Builder in X code, different ways to lay things out so that they kind of flex and move as you twist your phone, or if you're on a different sized phone.

 

Jamon Holmgren:

So all of these things were kind of the way that things were done, in many different ways with Native, but React Native was different. So the old days were just all kinds of different things. React native came in, and there's like, there's one way to style. And that's with the CSS-in-JS basically. So because this is the React Native Radio podcast, we're going to focus on that. We're going to focus on the CSS-in-JS that comes with React Native. This is... I mean like Robin, you said it's not really CSS. It's not really CSS, but it's really... It is based on CSS.

 

Robin Heinze:

It's CSS. It's familiar. If you know CSS, especially Flexbox, it's familiar.

 

Adhithi Ravichandran:

It's very similar, but just syntactically different. It's the same concept, it just looks different.

 

Jamon Holmgren:

You could probably copy and paste CSS and then just modify it to fit the format.

 

Adhithi Ravichandran:

Because a lot of that is CamelCase versus how CSS would be, where do you have the hyphenated.

 

Jamon Holmgren:

Right. So you have to change the naming conventions. And there are certain properties that aren't available. There are certain properties that work differently. For example, so Flexbox obviously, I feel like most people would understand what Flexbox is in our audience, but just to reiterate it's a new way of laying out web pages, actually. That's where it kind of came from, and allows you to do things like, "okay, if I want three boxes left to right, but I want the left two boxes to fill up half the screen and the right box to fill up the other half." You can do one, one, two, and it'll basically weight the size of the width of those boxes and fill in those spaces. It's a great way to do this sort of thing. Certainly works actually not too differently from how tables worked back in the day. Although CSS Grid is probably a better analogy. They brought that to React Native, and so you're able to use all of those things. The flow direction is vertical rather than horizontal though, because of the nature of where. And that's one key difference.

 

Adhithi Ravichandran:

That's definitely a difference. And in React Native, the flex is basically defined as a number. You say flex one, two, three, whatever. And in CSS, you'll notice that it's a string, I believe. So just subtle differences, but it's the same underlying concept that translates between CSS and React Native.

 

Jamon Holmgren:

CSS with an asterisk.

 

Adhithi Ravichandran:

Mm-hmm. Yep.

 

Robin Heinze:

Yes. And obviously it has sort of special considerations for Native specific styling and what the two Native platforms are capable of. Like shadows are very, very different.

 

Jamon Holmgren:

Shadows in particular, right? Like shadows in particular are strangely hard.

 

Robin Heinze:

Especially on Android. They don't...

 

Jamon Holmgren:

Yeah.

 

Robin Heinze:

-Android doesn't really have the concept of a box shadow like you would do on the web where you can manually define the radius and the dimensions. You can only give elements and elevation property and then Android sort of guesses what the shadow would look like from that elevation, which is interesting. So it's a bit harder to... Designers hate it because they can't implement exactly what they may have designed because you don't have that much granular control. But you do on iOS, but it's syntactically different than it would be in CSS.

 

Adhithi Ravichandran:

How often do we use shadows though? I don't use it too often. It's quite rare.

 

Robin Heinze:

I would say I've used it... I use shadows in pretty much all of the apps that we've built. It's pretty common if you have like a list of things and like your header has a little bit of a shadow, cause the list scrolls underneath it, like info overlays. Our designers usually put a bit of a shadow around the edge.

 

Jamon Holmgren:

Yeah. It's just giving information to the user that this is something that... I guess it just gives them a mental model of where these views sit in the hierarchy and what will slide under what. Especially list views are a big one because where does this slide, does it slide over? Does this slide under? if there's a shadow there, you can kind of tell.

 

Robin Heinze:

Yeah.

 

Adhithi Ravichandran:

With Flexbox we can also do layouts where we can do position based on whether it's an absolutely out versus a relative or they're going to be on top of each other.

 

Robin Heinze:

I've noticed that fewer position options in React Native than there is in CSS.

 

Jamon Holmgren:

What do you mean by that?

 

Robin Heinze:

So in CSS, you can have position relative, fixed, absolute, sticky, static. There's a lot more options, whereas in React Native, I think it's just relative and absolute.

 

Adhithi Ravichandran:

Yeah. And within that, you can tell where it can be placed, I guess, top or bottom.

 

Robin Heinze:

Right. Yeah.

 

Jamon Holmgren:

It gives you a little bit of an appreciation for what browsers have implemented under the hood. Because a lot of this stuff has to be done kind of manually on mobile. We don't have the benefit of the browser's layout engine working for us. Now, what we do have is a thing called Yoga, and this is an open source library from Facebook that is really what powers the Flexbox layout engine under the hood. It has bindings for Android and iOS, and it will take in Flexbox information and then lay out on the screen the elements in the order that you would expect them to be. And it's a really cool system. I don't know much about it, to be honest. I haven't ever worked on it. I haven't actually contributed to it or otherwise even looked at the code, but there is a website for it. Yogalayout.com. I think it is. And when you... If you just search yoga layout you're not going to... You got to just go to yoga.

 

Robin Heinze:

It's one of those really hard libraries to Google.

 

Adhithi Ravichandran:

Mm-hmm.

 

Jamon Holmgren:

Yeah. Just go yogalayout.com.

 

Adhithi Ravichandran:

And they have a cool playground too. Sometimes when you want to mentally visualize something, you can use their model. I've used it several times to just look at, "Okay, how does it look?" Cause sometimes you just get confused between different flex properties, like align content versus align self versus align items. So you can visualize them.

 

Robin Heinze:

I still don't know the difference between align content and align items.

 

Adhithi Ravichandran:

Think align items, aligns items within that container.

 

Robin Heinze:

I don't think I've ever used align content because align items always does what I need.

 

Jamon Holmgren:

Does it have something to do with the text content rather than items?

 

Robin Heinze:

Well cause text you align with text align.

 

Adhithi Ravichandran:

It defines the distribution of lanes along the cross axis, and this only has effect when items are wrapped into multiple lines using flex wrap. So you won't need it until you have like multiple lines of content.

 

Robin Heinze:

Okay. Today I learned,

 

Jamon Holmgren:

Yeah. These are kind of the types of things that we don't really think about generally. We just use the properties, and the people that make Yoga they have to be thinking about all these different situations and having some way to deal with them. And Yoga was built in C++, so it can actually be used anywhere. It has a low number of dependencies. It's actually small. You would think that something like this would be big.

 

Adhithi Ravichandran:

I didn't know that. I didn't know it was built on C++.

 

Jamon Holmgren:

Yeah. And so I would assume you could probably it in Windows, React Native Windows, as well. I actually haven't checked to see what they use there, but this is the type of thing that's pretty cool and allows for a lot of power. It's very cool that they made that as kind of a separate module to allow other... There are other systems out there that use it. I believe that it is used in other open source libraries, obviously React Native is the biggest though.

 

Jamon Holmgren:

When we're talking about React Native styling, there is StyleSheet, which comes from React Native. At Infinite Red, we don't really use StyleSheet. We've used pretty much just bare objects. And the reason is because we use TypeScript. And TypeScript, if we just type each individual rule or not each individual rule, rather each kind of block of rules for a particular style, then we can actually get the benefit of auto-complete and TypeScript. So just to describe to our users, we'll say const button style. And then because it's TypeScript, we'll add the type information colon... I guess it wouldn't be button style. Let's say-

 

Robin Heinze:

It would be view style, image style, or text style.

 

Jamon Holmgren:

Exactly. So we would say like const header style equals colon view style equals, and then we would give an object with different properties and we could auto-complete so we can start typing in background and it'll auto-complete to background color. And then it also knows what types of properties you can give it. And that's very, very powerful. It looks a little funny, but it works quite well. When you're trying to find something, everything is auto completed. You have type checking and you can also spread those objects into each other. So that makes it so that it's much, much easier to kind of use it in a... You can compose styles from it rather than inheritance or anything else like that.

 

Robin Heinze:

I often use it to remember what the various options are for image resize mode without having to go look at the docs. So that's nice. And yeah, like Jamon said, we use it for composing styles a lot, especially if we have higher order components which we use quite a lot. We'll have our own text component which wraps the bare React Native text component. And almost every time we have a higher order component like that we'll include a style prop, which you can use to override any styles that we define within the component. And so we'll use just simple JavaScript spreading to combine the two styles together, which is really useful.

 

Adhithi Ravichandran:

Cool, interesting. I use StyleSheet all the time on most of my projects. And sometimes I use styled-components, which is kind of a third party library which has CSS and JS. But StyleSheet works for the same... We don't get the benefits of TypeScript as you were talking about, but you can still do all of this stuff with higher order components and all of that stuff with just the bare minimum style sheet that comes with React Native.

 

Robin Heinze:

I do think TypeScript was the primary reason that we-

 

Adhithi Ravichandran:

Moved away.

 

Robin Heinze:

-moved away from title from StyleSheet.

 

Adhithi Ravichandran:

Have you guys used styled-components?

 

Robin Heinze:

I haven't.

 

Jamon Holmgren:

I've used it in a kind of side project, a little playing around with things. I've also used Emotion, which is another popular one. And some of these are... Like Emotion, you can actually use more... From what I understand you can use basically the CSS. Like you can actually copy and paste CSS in, and it'll translate it to the React Native styling system.

 

Robin Heinze:

About what your experience has been like with styled-components and what you think the advantages are over just regular components with styles passed in?

 

Adhithi Ravichandran:

Sure. On some projects I've used styled-components. The good news is you can share it between React and React Native. Like when we use the regular StyleSheet with React Native, we have the different... We don't have CSS. If you were to just have the similar styling of CSS and you want to share between React and React Native, I've noticed styled-components are useful because you literally copy paste. And it's also... It generates a unique class name for the styles. So you don't need to keep track of class names. That's kind of nice. It's also been just easier if you have both React and React Native projects to maintain, and if you have like a CSS coder who's not comfortable with just the way things look in React Native at styling, they prefer the styled-components. So we've noticed that when we onboard somebody with extensive CSS background, they just prefer styled-components.

 

Robin Heinze:

So it's using more traditional CSS to style React Native components?

 

Adhithi Ravichandran:

Yes.

 

Robin Heinze:

Oh. Okay.

 

Adhithi Ravichandran:

And you can also, it basically styles the components. You can do it based on props or a global team. So it supports things like that as well.

 

Robin Heinze:

I will throw out the opposite scenario, which is that React Native web. If you're using React Native Web for your web project, in order to share code with a React Native app, React Native Web lets you use React Native styles for your web components. So it's kind of the reverse.

 

Adhithi Ravichandran:

That's pretty awesome. Yeah. It's literally the reverse you code React Native views and texts components, right? For the web.

 

Robin Heinze:

Yes.

 

Adhithi Ravichandran:

Okay.

 

Jamon Holmgren:

Yeah. And I don't know if this is true about styled-components, but Emotion allows you to... For example, if you were to say background, color, colon, and then because you're using a style.view, I forget what it's called, but you're using the back ticks to interpolate. You can actually pass in a function. And so this what looks like kind of a string is... You can pass in a function that will actually take the props of the component it's in. So like when you use the string later, when you use the style later, you can actually use the props and say, "Okay, well I'm going to style this based on the props." And so when you pass in the style, not just like a static string. You're actually getting something that's kind of a living thing that can respond to the props that were passed in to that particular view. But you're actually kind of like... you're actually building with style.view in Emotion. You're actually building a view in a lot of ways.

 

Robin Heinze:

You understand how all these various like style strategies work? What if you kind of want someone else to do a lot of your styling for you?

 

Adhithi Ravichandran:

Then we just get a UI kit, which is... There are plenty of UI kits for React Native, which is kind of nice.

 

Robin Heinze:

Exactly. There's things like UI Kitten, which we've used quite a bit here at Infinite Red there's React Native Paper, I think is another one.

 

Jamon Holmgren:

React Native Elements.

 

Adhithi Ravichandran:

I've used React Native elements. That's pretty cool.

 

Robin Heinze:

I know with UI Kitten, it's a component library, meaning like it has buttons and forms and popovers and various sort of useful common components. And it also has a theming... I don't know what to call it, a theming structure which you basically wrap your app in and you can do things like switch from light mode to dark mode, and it basically gives you a color palette to work with and sort of helps you theme your entire app.

 

Adhithi Ravichandran:

I think this sounds very similar to what React Native elements does too. They have their own components for like buttons and all sorts of stuff, and I think the recently added support for web as well. So they're truly cross-platform now.

 

Jamon Holmgren:

That's cool. I found with React Native elements that it has some really cool theming functions and stuff like that. So I think that's kind of its strength. It was a little lacking on the prebuilt funk or pre-built components where I think UI kitten was a little more full featured on that side of things.

 

Adhithi Ravichandran:

Typically, I've used these UI toolkits for like prototypes and quick demos. I haven't really used it to build a product to ship to a client. I haven't done that yet.

 

Jamon Holmgren:

Our designers will come up with a design system, almost always, for the designs that we do for the mobile apps that we do. And I'm going to give a little shout out to our designers here. They really understand mobile, and one of the things that they really do well is not design us into a corner. It's a big thing because Robin was saying with Android not supporting drop shadows the same way, et cetera. If a designer gets you in a position where you can't replicate or you have to do a lot of really custom things to replicate it, it can really extend the expense of a project as well as the maintainability toward the end. They do a great job of that. And they also do a good job of designing kind of a design language around how you approach the app all the way through which translates from their side.

 

Jamon Holmgren:

I remember with working with designers way before I had my own design team and they would sometimes like every page was totally custom. Like they would just approach it like it was a blank slate, and you to like completely redesign each page. And there were very few common elements, but with this they'll come up with a design system that the buttons look the same. They may have a few properties different here and there, but you're using kind of the same buttons or you're kind of using the same colors all the way throughout the app so you can use theming. And that's actually a better experience for the user anyway, because as they're looking at it, they can notice familiar concepts and know that's about know that's a tab or whatever. It works all the way through. I'm a big fan of that. It definitely tightens up our code, and we can kind of use that to compose styles, to share styles all the way throughout the app.

 

Adhithi Ravichandran:

Yeah. That consistency is really important to the users as well because they want to have the memory of what the button looks like, what it does. They don't want different components, different colors and themes. So yeah.

 

Robin Heinze:

I would say using... Going with a UI library and all-in-one UI library like UI Kitten or React native elements is a good thing to do if you're maybe not working with a world-class design team. Those libraries can sort of help nudge you in the direction of having really consistent elements throughout and a consistent look. And I would say if you're working with a design team, and you're also planning on using one of those UI kits make sure your design team is on board because it can actually be quite difficult to try and implement a custom design while also trying to use prebuilt UI elements.

 

Adhithi Ravichandran:

I agree. That makes sense. You know, if you're just a developer kind of silo, don't have a design team and asked to do all of it, then the UI kits are really useful at that point.

 

Robin Heinze:

Definitely.

 

Jamon Holmgren:

I want to talk about one more thing and I'm actually... If it's okay, I'm going to use the time that we would normally spend on a weird bug. I'm going to... I don't think the three of us necessarily have a great, weird, weird bug for this week. So I'm going to use that time for something else styling related and that's to talk about apps that allow you to lay things out visually and actually come up with code like code that actually you can copy and paste into your app. Now, I don't know if you two have used any of these in the past or explored any of these in the past. Okay.

 

Adhithi Ravichandran:

You can literally do that with the Yoga playground that we talked about earlier. You can position your elements and design stuff and get the code for it.

 

Jamon Holmgren:

You get React Native code?

 

Adhithi Ravichandran:

Mm-hmm.

 

Jamon Holmgren:

That's awesome. I actually haven't used that.

 

Adhithi Ravichandran:

See Jamon, I thought you were talking about Dreamweaver.

 

Jamon Holmgren:

I did use Dreamweaver for years. I never used the visual thing, and most people when they think Dreamweaver, they think the visual editor. But it was a pretty good code editor in its own right. It mostly got a bad rap because the visual editor was complete garbage, and I think people have tried to do this for years and years. This is something that has always been like, "Well, if the designers could just lay it out and give us the code, then we wouldn't have to worry about that." We wouldn't have to do that. These are probably people like me who don't want to do it. They're just like drop it in, and then I can wire up all the data and be happy.

 

Jamon Holmgren:

But the promise has always been bigger than the actual execution of it. But there are a few out there now that are starting to get there. So like Framer X.

 

Robin Heinze:

I've never heard of Framer X. What's that Jamon?

 

Jamon Holmgren:

If you got a framer.com, it is... They're not a sponsor. I'm just throwing it in there as an example of this. It is a prototyping tool. So you can actually do things... Now, I don't know how good their React Native support is. I know that they'll export to React. I'm pretty sure, but framer.com and check that out. There's another one by our good friends over at Geeky Ants, they built one called Builder X. I guess the X theme is sort of out there. This one, it definitely supports React Native because they were...

 

Jamon Holmgren:

They're friends of ours and they do React Native. They do React, and that allows you to design things and you can then copy and paste the React Native code. This is something that I remember Sunkit giving me a demo of that at Chain React one time, and my mind was blown. Like, wow, that's, that's really cool. And from what I understand, they do use it over there at Geeky Ants. Although I think they do a lot of Flutter and whatnot as well. But for their React Native work, I'm pretty sure that they use this. And the idea is designers and developers on one app. You kind of have that, that meeting of the minds. One of the problems with that is that. like designers and developers have different priorities. So if you have a developer design a design tool, it's not going to feel right. And if you have a designer to design a developer tool, it's not going to feel right. So getting that right is extremely difficult and actually been an elusive target I think to this point.

 

Adhithi Ravichandran:

We've been using InVision for our prototypes from the designers, and that gives us all the styling information, but it's in CSS, which is still okay. We can still translate that to React Native pretty quickly. So that's been useful like for shadows and all sorts of stuff.

 

Jamon Holmgren:

We did an internal project, which I don't think I've ever talked about publicly to this point. We did an internal R&D project where we could take a Sketch file and translate it into React Native basically. And it would become more or less a script using Glue Gun, which is the library that we built for CLIze.That's a tough problem. We would have had to put a lot more investment into it than we did to make it useful. Not only that we actually found that the tough thing was getting any designers, didn't matter really how good they were, to use Sketch in such a way where it turned out good code. And I feel like that was something that... It was an interesting idea that really, again, fell over in the execution. This is just something that I think we should definitely have touched on in this. That actually brings me to my last question for you two. What do you think is the future of styling in React Native?

 

Robin Heinze:

Depends on how far in the future we're talking about.

 

Jamon Holmgren:

45 years.

 

Robin Heinze:

45 years?

 

Jamon Holmgren:

You'll be talking about the old days.

 

Robin Heinze:

I definitely think styling is it's bound to move towards visual based layout. Being able to define what you want visually and have that translated into code. I think we'll get there.

 

Adhithi Ravichandran:

Absolutely.

 

Robin Heinze:

I think it's a hard problem, but I think we're moving towards the solution and I think ultimately that will help bridge the gap between design and development.

 

Adhithi Ravichandran:

Yeah. I don't see why not because we have so many technologies to do other things. Because I think having building blocks where we just have the designers put pieces together and generating code for at least a styling code would be easy. That'll make a developer's job super easy. So we just need to work on the actual functionality of that app at that point.

 

Jamon Holmgren:

I agree. I think the problems are not technical. I think the problems are definitely more around getting designers to design in a developer friendly way and getting developers to adjust their ways. Because developers who are used to handcrafting code have certain expectations around what that code looks like, how it works, and you're not going to get that if you get out of generated code. So how do we do that? Now, Like X Code with interface builder, that's been a thing for quite a while actually, but I actually don't know how many designers out there use interface builder to design. I doubt that's all that common to be honest. So you're still relaying it out again. This a tough part, really. You're translating from one team to another and it's always lossy. Very cool. Well, I think that's a good place to end the episode.

 

Jamon Holmgren:

Thank you both for your insight into this. This is definitely something I'm interested in, but I'm just not very good at. It's still something that I guess you just have to do a lot and I don't do it a lot. And there were some things that we didn't touch on. We didn't talk about how we account for different device dimensions, other strategies for organizing styles, co-located versus actually in a previous episode, we talked about co-located versus centrally located files. And that's the sort of thing that would be fun to go into, but we're out of time today. So I'm going to wrap up here. Where can people find you at Adhithi?

 

Adhithi Ravichandran:

I'm on Twitter @Adhithiravi.

 

Jamon Holmgren:

Perfect and Robin?

 

Robin Heinze:

I'm @Robin_Heinze.

 

Jamon Holmgren:

And I'm @Jamonholmgren, you can find our show Twitter @reactnativeRdio and as always thanks to our producer and editor, Todd Werth. Our transcript and release coordinator, Jed Bartausky and our social media coordinator, Missy Warren. Thanks to our sponsor Infinite Red, check us out @infinite.red/reactnative. Special thanks to all of you for listening to us today and hopefully every week. Make sure to subscribe and tell a friend if you have enjoyed this episode and let us know how you liked the episode and the show on Twitter. We enjoy hearing feedback, positive or negative. We'll learn from it all. See you all next time.