Forem: Laura buns

So you want to make a Twitter bot (2.5/3)

Laura buns — Sun, 22 Dec 2019 15:51:45 +0000

Sorry for going final harry potter movie on you. Anyway

OMG OMG it's ALMOST part 3 it's THE FUN PART TODAY – up until now all the steps we have made (see part 1 and part 2) are mostly plumbing, you gotta do these for each bot (there are a couple tricks to automate this. You can duplicate repos and heroku apps, and you can get all your keys using a single app like this).

However our actual posts leave a lot to be desired. i can't teach you to be funny (if i knew the secrets to that I'd be funny myself). In my own bots I use a lot of images to accomplish this. In cases like @readyforspoons or @fakefantas they are the whole point of the tweet. the dirty little secret here is that they are webpages:

There's a tool called puppeteer that i never know how to spell and that more serious people than me use for actual purposes that lets you automate spinning up Chrome (okay it's Chromium. Who cares, not the point), taking a screenshot of certain dimensions, and saving it to a file. This is a very neat closed loop, it means we can develop this in isolation* and then from our tweeting app, pick up the image and tweet it.

okay, almost isolation. In most cases you are gonna get some more stuff back from the page, like the text for the tweet or whatevers. More on this later

I'm sitting on a mcdonalds listening to fall out boy massively hungover thinking about deep stuff so let's make an aesthetics bot that makes these poster things you see on tumblr but it's lyrics from smash mouths 'all star' instead. (This is a terrible bot idea don't do this there's v little variation)

Now, research is always an important first step, there's a lot of different aesthetic quotes and we gotta figure out how much variation we want. Do we wanna cycle through images or just have one? (we are gonna have just 2 bc im lazy). If we are using random images, where are we gonna credit the authors? (i mostly riff of brands and for this I'll just use photos I took, you too can use VSCO on your phone). How do we wanna show the text? italic arial is a classic but if you want a challenge, doing chat bubbles is a cool idea. (we aren't)

I had a play around in sketch and much to my despair this looks exactly like a normal aesthetic post. there's no joke here, no clever subversion. Just teenage angst. I don't care. We are doing this anyway, you find a way to make the content work on your own:

Websites

I have a bit of a confession to make, I got not clue how to make a webpage from scratch, the script and css tags elude me, so let's just copypaste some boilerplate from w3schools into a glitch sandbox because why not:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <h1>Okay this works</h1>
  </body>
  <link rel="stylesheet" href="/style.css" />
  <script src="/script.js"></script>
</html>

And throw in some CSS for styles:

/*
so we cant actually use real arial! this 
is bc your computer probably has it 
but the remote computer running this doesn't.

what this means is that I went to 
google fonts and picked a look-alike. Close enough!
*/

@import url('https://fonts.googleapis.com/css?family=Archivo:600i&display=swap');

* {
  /*
  worlds barebonest css reset
  */
  margin: 0;
  padding: 0;
}

body {
  display: flex;
  align-items: center;
  justify-content: center;
  /*this centers our heading*/
  background: url(https://cdn.glitch.com/15a843df-5327-4b8b-b3ef-ca56f7e35e5e%2F46653054781_f96753b868_o.jpg?v=1576936807505);
  background-size: cover;
  width: 100vw;
  height: 100vh;
  /*
  vw and vh are viewport units, 
  they are 1/100th the size of the 
  browser window, so using 100 means
  we tell body to fill everything.
  */
}

h1 {
  color: #AF9C3E;
  font-family: "Archivo", sans-serif;
  font-weight: 600;
  font-style: italic;
  text-transform: uppercase;
  text-align: center;
  /*
  this is a design thing
  */
  text-shadow: 2px 2px 0 #000;
  filter: blur(.1vw);
  /*
  we can use viewport units 
  for font sizes too and this will 
  make them scale with the window!
  */
  font-size: 5vw;
  padding: 0 10vmax;
}

And we got something that looks like this (I started this from scratch on glitch. At this point all we really care about is making a stand-alone webpage, we'll 'integrate' it into our 'pipeline' later:

Let's actually plug some quotes into our JS (Get them here)

const ALL_STAR = [
  `Somebody once told me the world is gonna roll me`,
  `I ain't the sharpest tool in the shed`,
  `...`
];

const quote = ALL_STAR[Math.floor(Math.random()*ALL_STAR.length)];
console.log(quote);

If the console.log is actually working let's plug the quote into our heading and see if that works out okay

document.querySelector("h1").innerText = quote;

Fun fact! We can use this oneliner because our script tag is at the end of our index.html, so the script is not gonna run until the browser has parsed the whole document, meaning at this point it already knows what our elements are.

Do you know what would be, like, real cool, right now? let's randomise the text color, i'm sick of that yellow already. I'm sure we can do npm i random-color-or-whatever but let's not do that because css is awesome when you are only doing websites for the last version of Chrome

In our CSS, let's switch our color up to use HSL. HSL rules, it stands for hue, saturation, and luminosity and what this means is that if we mess with the hue we get a whole rainbow of colors that all match the mood we are going for, and we can plug the hue as a css variable:

h1 {
    ...
  color: hsl(var(--hue, 0), 80%, 53%);
  ...
}

That we then set from our javascript like madmen:

const $h1 = document.querySelector("h1");
$h1.innerText = quote;
$h1.style.setProperty("--hue", Math.random() * 360);

(The second argument in var(), where we got a 0, is a fallback. if the CSS parser can't find a variable named --hue it'll use that value. For this use case it doesn't really matter because this is a closed loop and we know this variable is gonna be put in, but picking up good practices doesn't hurt.

Let's clean this up and do another for the text transform because omg this is FUN

const hue = Math.random() * 360;
const textTransform = Math.random() > 0.5 ? "lowercase" : "uppercase";
$h1.style.setProperty("--hue", hue);
$h1.style.setProperty("--text-transform", textTransform);

You might have noticed that our hue thing is mostly working but also we got a problem, when the hue is on the blue range it kinda blends with our background. What's really cool about HSL is that we can sorta fix it? we know that when our hue is around a certain value (i fiddled with the devtools to find out which, if you don't wanna do it, it's 200-300) the luminosity is not enough and it just so happens that we have a luminosity value and it's another number we can mess with.

We can make something far nicer and maths based here but i don't have paper at hand and also i'm not a fucking nerd so I did this and it works out fine:

const hue = Math.random() * 360;
const textTransform = Math.random() > 0.5 ? "lowercase" : "uppercase";
$h1.style.setProperty("--hue", hue);
$h1.style.setProperty("--text-transform", textTransform);

if (hue > 200 && hue < 300) {
  $h1.style.setProperty("--lumi", "80%");
}

And plugged the --lumi variable in the css

h1 {
    ...
  color: hsl(var(--hue), 80%, var(--lumi, 63%));
  ...
}

There's like a lot you can do with just HTML and CSS to generate images for bots. Here's what I ended up with. Try out randomizing other values! If you wanna move your text flexbox is fantastic for that. Other things I've done myself is use 3D transforms or play a youtube video in the background to capture stills of it!

Let's deploy

This is gonna move on to a final fourth part because i'm running out of weekend but let's get this integrated into our bot anyway,
One last thing! Because of annoying things like 'security', or 'progress', or 'chrome being a little bitch' having some static HTML website locally just doesn't cut it for a lot of things, including screenshotting it. You might also wanna scale up your JS to import multiple files or use SASS. Three very straightforward ways to take what we've got and put it on a real URL instead of a file URL:

We keep it on glitch and do nothing else

It does have a URL and this is gonna work - only thing is this is all a bit fragile, normally you want your code yo be a closed system.

If it's only static like this we can use `serve`

If you download this stuff as a zip and open a terminal and type npx serve you will immediately get a localhost url pointing to this folder. This is powered by the serve NPM package

If it's a bit fancy and you want SASS or babel or whatever

Use parcel. use it like serve (npx parcel watch index.html). This will also serve your website on a local URL but behind the scenes it's compiling your js and css. You can read the docs to get an idea of the plugins you can use. This is what I do with most of my (newer) bots.

All set!

Next week we'll use puppeteer to take an image out of this and link it with the bot. have a good one!

#twitter

So you want to make a Twitter bot (2/3)

Laura buns — Sat, 14 Dec 2019 15:03:41 +0000

Hi! You might wanna check part 1 first. If you are back from it we left with a bot in a folder in your computer (did you already set up a repo? pls do, if you have skip ahead). We have a working twitter bot and really we could just put it on a timer and that's it, we are good.

However, and you will have had this problem already if you started torrenting movies back in the 2Mb broadband days, you will also wanna turn off your computer at some point. And have the bot still running. The surprisingly uncontrived solution for this is just put it in somebody else's computer (like a website!)

Doing this is kinda cool because we are still doing a pointless shitposting exercise but we are using industry standard tools for this, which means this is a fantastic way to learn about fancy-ass things like CI or devops, or servers, or deployments, or containers all without actually doing any of the work.

First things first let's get this into a repository

So, the way code works most of the time is that you will have a repository (this is like dropbox but for nerds) and then from there services can deploy it to a server (this is moving the code to somebody else's computer and getting it to a state where it can run). Sometimes you run it on a different computer first to test it and if that's okay you then deploy it.
In most cases this is all automatic. When your code changes, the repo lets the testing computer know – it will then kick off the tests, and if they all pass then it'll let the deploy computer know to do it's thing. This is called CI and we are gonna do a very basic version of it (without testing bc we are lazy)

For this guide we'll be using GitHub as a repo and Heroku as a server. GitHub because it's super popular, and Heroku because it's free. Sign up for both if you haven't.

Getting our code ready for open source

So I forgot this on part 1!! You will need a package.json file to continue. When you were installing twitter in part 1 you might have gotten an error and a package-lock.json file was created. This is all good! Think of package.json as some basic info about your app. What it is, what it does, what dependencies does it have, etc. When we deploy the app we will install it and this file is how the other computer figures out what modules your app needs.

You can run npm init -y in the same folder your app is to generate one. Make sure it's adding twitter as a dependency! If it's not, you can run npm i twitter again to add it.

Now, as you might remember your code has secrets in it, the tokens and whatnot.

const client = new Twitter({
  consumer_key: "314gvas...12kjbh31n2",
  consumer_secret: "bd129u...21hjbv3",
  access_token_key: "89xzcyh...ads",
  access_token_secret: "98217...gyve98"
});

While you can store them on a private repository and call it a day this is a bit limiting. You can also just delete them and add them manually whenever you wanna run the bot? but this is not gonna fly when hosting it on a server, and it's a pain in the ass.

Like most problems you run in computer science, this is a problem many people have had before and we have a lovely industry standard way to handle secrets called environment variables.
The gist of it is that most operating systems have this concept of OS-level text-based key-value variables that:

the entire computer has access to
live outside of your code

You can set these via the terminal, but there's this handy little package on NPM that lets you set them in a file, the idea here is that you don't commit this file, and instead every computer that runs the code (every environment) has its own private and personal copy of these variables.

Let's try this! Install dotenv.

And now let's update our code.

require('dotenv').config() /*put this up top*/
...
const client = new Twitter({
  consumer_key: process.env.consumer_key,
  consumer_secret: process.env.consumer_secret,
  access_token_key: process.env.access_token_key,
  access_token_secret: process.env.access_token_secret
});

and put our secrets in a .env file

consumer_key=314gvas...12kjbh31n2
consumer_secret=bd129u...21hjbv3
access_token_key=89xzcyh...ads
access_token_secret=98217...gyve98

Give tweeting (node index.js) a go just to make sure everything still works!

if it doesn't (shit happens, it's okay) try console.log(process.env) to check if your variables are in there.

Okay, now back to git

GitHub has an amazing desktop app that lets you get away with not using the command line and makes the dropbox comparison very fair. use it and create a repository.

You may be asked about creating a .gitignore. This file lists directories and files you don't wanna commit to source control. it's where you can put stuff like node_modules or .env. Files here will be effectively invisible to git.

If you are asked to create one choose node, if you aren't, let's make one. in both cases, let's make sure to add our .env to it:

node_modules
.env

And now you wanna commit and push your code. There's this concept of branches that we are not gonna get into. master is considered the main branch (v problematic, sorry) and you can branch out if you wanna do some work that is gonna take a while and it's not ready to just go into the prime time. you can then merge your branch back to master. In any case, push to master for now.

You wanna end up with something like this, if you see a package.json at the top level you got this!

Coffee break

Not for you lol for me, i've been hiding in an office corner typing this for the last hour, gonna go replenish. I'm not actually having coffee, i have this whole thing about not drinking calories, not the point.

Okay So at this point we got our code at a point where it's deployable. This means that we can automate the steps required to get it to download and run in a fresh computer, which is what we are gonna be up to next.

Heroku time!

let's get into the Heroku dashboard and just like with the twitter API, we gotta create an app here. After doing that you'll notice there's a bunch of stuff (by the way, if you are skimming through, you can sync Heroku with dropbox instead of github! You can do that instead of everything in the previous steps)

The steps here are straightforward too, get our app into Heroku, put the environment variables in, give it a try, then finally set a timer to tweet for us and forget about it.
(We can also put the environment variables first but where's the fun in THAT)

At the time of writing the top navigation bar should have a literal 'deployments' button, and going there will get you to a page where you can sync with a GitHub repo. Connect yours and you are done. Just one more thing! there's a checkbox that lets you redeploy every time you push changes, you probably wanna tick this too. It's good practice to have your master branch in your repo in sync with the deployed code.

Now heroku is downloading our code and trying to install it in the background. Exciting! You can check the progress in the "Activity" tab.

While that's going let's throw in some variables! Again at the time of writing you can find 'em on settings, and you'll see that they follow the same key=value structure that we have in our .env file. Add all of them and save.

Buildpacks lol

If you have been keeping an eye on your deploy you'll have notice it has failed. That's because we are using node, and Heroku just gives us a barebones OS. To fix it you can add 'buildpacks' they call them in the Settings page. This is just a collection of preinstalled software. Add the one for nodejs and try deploying again. This one should work!!!

to quickly test if everything is in order you can open a console from the 'more' menu. This lets you run terminal commands on the remote computer, so you can do node index.js just like you did in yours. Except this time it's all in the cloud. Did you get a tweet out? Please tell me you got a tweet out.

If all is good this is pretty cool because this is how you deploy anything not just twitter bots. You could make a website on Netlify or dip your toes in CI with Travis if you wanted.

A fancy egg timer

Now, we sure have wasted a lot of time but we haven't fixed the problem we were trying to fix where we want the thing to run on its own lol. Heroku has this concept of addons and what you can do is install the scheduler, which runs console commands at set times.

After adding it to your app all that's left to do is configuring it to post node tweet.js as much as you wanna. if you have trust issues (like me) you can also install papertrail. This will let you see the logs for what your scheduler is doing and in the case your bot isn't posting, help you figure out why!

Woo!!

In the next part we are gonna make the bot actually funny. or not, but we are gonna go over some of the tools I use myself to make the actual bots. We'll be going through stuff like randomising posts as well as doing PICTURES.

twitter

So you want to make a Twitter bot (1/3)

Laura buns — Sat, 07 Dec 2019 12:01:24 +0000

One of my hobbies is creating twitter bots, you might be familiar with @fakefantas for example? if you aren't that's okay that's not the point. The point is that sometimes people ask me how to do these, and I love talking about this because on paper there's a lot of complexity involved but when you break it down into parts it's pretty manageable!

(Most of my bots just tweet random stuff on a timer, this means they don't listen to replies or know what they posted before. This helps a lot with complexity but hopefully by the end of this series you'll be able to work out how to add this)

Bots are a cool 'problem' to solve because they sound daunting at first, it's a lot to take in! However when you break the problem into smaller problems now you got a lot to take in but also you gotta take it in 3 times. PROGRESS.

When it comes to bots, you have a part that's creating the content. This part takes thin air and produces content. This is hard because you gotta be funny but also sometimes you'll want images or even video, and we gotta automate THAT somehow I normally use I normally use puppeteer.

You then have a second part that takes your content and turns it into a tweet that shows up on twitter.com. This is hard because backend development and API keys are b🔥ll👎sh🙅‍♀️t but thankfully what we are doing is a pretty textbook example.
There's a third part where we deploy this to somebody else's computer and have it run automatically, instead of us doing the work I use Heroku. for this but something like Glitch can work out fine too!

On this first tutorial I wanna focus on the second part. (bc i can't count) We are gonna create our app on Glitchand by the end of this we are gonna be able to type npm run tweet and see the thing pop on our screenies.

A thing! We are using Glitch to avoid setting up Node locally, but it effectively hosts and deploys our code so it can do a lot of the third step for us. I personally use GitHub+Heroku because they give me more robust tools around collaboration and scheduling.

Tweeting something

Let's start with the basics, let's make a JS function that gives us the day of the week, we are gonna ignore timezones because thats not the point today and not make it any more complicated than it has to be.

/*tweet.js*/
const weekdays = [
  "Sunday", /*america wtf*/
  "Monday",
  "Tuesday",
  "Wednesday",
  "Thursday",
  "Friday",
  "Saturday"
];

const tweet = function () {
  return `Wooo todays a ${weekdays[new Date().getDay()]}`;
};

console.log(tweet());

if you run node ./tweet.js (and it's a Saturday) you'll now get Wooo todays a 6. Once you're happy, one final thing is that console logging rules for debugging while we make a file but when we are done this will have to be part of a larger system, so let's export tweet instead! We'll import it later. Feel free to make any changes, all we really care about here is that calling tweet() gives us a text under 280 characters.

- console.log(tweet());
+ module.exports = tweet;

leave that to sit in your kitchen counter (or wherever you code) and let's focus our attention on becoming a Twitter developer:

Making a Twitter app

We will wanna create an 'app' in dev.twitter.com If you click around you will see that Twitter has really lost its cool over time about this. Now luckily our use case is still covered.

The developer console is always changing over time as Twitter becomes less of a quirky website and more and more of a soul crushing direct competitor to NBCUniversal but the core concept is.

You need an 'access token' (and secret). These tell twitter what user is posting to it (instead of a username/password combo)
To get the access token you need to make an app that will have a 'consumer key' (and secret). This tells twitter what 'app' is posting to it (instead of a users browser). Four keys total. All good things come in pairs.
To obtain your consumer key/secret you wanna create a 'twitter app'. As of the time of writing, after creating an app twitter will conveniently give you the access token/keys for your current account which is hella nice

Find that 'create app button', click through and fill out the form. Do whatever song and dance Twitter requires you to do and by the end you should be able to find a page with your tokens:

Important These tokens are like your password and grant anybody with all four of them access to your Twitter account. Treat them carefully!!

Let's go back to coding

If you had a bit of a wander around the twitter developers site you'll see there's hella detailed documentation for how to post to twitter and make authenticated requests and a bunch of other stuff. Now, something I love about using node (and that my ex that was more into reinventing wheels than into driving hated) is that somebody else has already done our job for us.

Have a read through the page for the twitter package and you'll see that we already got authentication (our 4 tokens!) covered all the way at the top and tweeting a bit below, will it work? let's npm i twitter and find out!

/*index.js*/
const Twitter = require('twitter');

const client = new Twitter({
  consumer_key: "314gvas...12kjbh31n2",
  consumer_secret: "bd129u...21hjbv3",
  access_token_key: "89xzcyh...ads",
  access_token_secret: "98217...gyve98"
});

client.post("statuses/update", { status: "bananas lol" }, function(
  error,
  tweet,
  response
) {
  if (error) throw error;
  console.log("yay!");
  console.log(response);
});

We aren't using our tweet() function yet because it's always good to test parts in isolation first. Imagine this didn't work. is the problem here or in tweet.js? Nobody knows, it's chaos. Making things as small as possible helps you find bugs faster.

Having that said, in this case we will hopefully get lucky and this is gonna work out of the box! Try running node index.js

This got 2 likes before i deleted it i shit you not. Okay, time for a trial by fire! let's plug in our tweet() function

/*don't forget to import this at the top!!*/
const tweet = require("./tweet.js");

/*and keep the authentication stuff in the middle the same*/
client.post("statuses/update", { status: tweet() }, function(
  error,
  tweet,
  response
) {
  if (error) throw error;
  console.log("yay!");
  console.log(response);
});

(Goes without saying, you will wanna use your bot account, not your own account) but the larger point is we did it!!!!!
In part 2 we will be moving this from our computer to Heroku and setting it up so it tweets every hour or whatever. In the meantime, why not come up with a funnier tweet() function?

Lost? here's what we've got so far on glitch. You'll notice that instead of using the tokens straight up I'm using this thing called process.env. As I said before you don't wanna reveal your tokens! Not even in code!!

We'll go into detail about this in part 2 too but for now either don't let your code leave your computer or use something like dotenv.

The web without the web

Laura buns — Thu, 01 Aug 2019 12:43:56 +0000

1.

I built my first website when I was 14? It was a fansite for the Sims. It used tables and the colours wouldn't pass any accessibility (or aesthetics, for that matter) checklist. If I remember correctly it was a combination of making the visuals in dreamweaver to then copy/paste the generated HTML and CSS into a PHP backend that I made myself (you can imagine how that looked on the inside).

This was a very important website not just because it somehow got relatively popular but it was also important for me as it became my personal playground. I taught myself CSS to make the layout nicer, and in the process I picked up enough design skills to be employed as a designer for 4 years. I started doing banners and animations using Flash (from macromedia back then!).

The web 2.0 era arrived shortly after and I started hacking together mooFx scripts to make things move and be cool. I wasn't entirely sure about what was going on in my code and I missed to PHP standard library dearly but I powered through. Eventually picked up jQuery and for a buncha years that was all my understanding of the DOM really.

I learned more about HTML and CSS. I learned how to write semantic and accessible code. I learned how to scale up CSS architectures to prevent spaghetti code.

For a while I had this personal website that was like a Mario World stage and everything moved and it used CSS animation and some JS sprinkles to add infinite clouds and stuff.

I fell in love with all the cool shit I could build.

![](https://thepracticaldev.s3.amazonaws.com/i/ha6dim4gjonlx8ed3g6m.gif)

2.

I eventually became a somewhat respected frontend 'engineer'. I do talks and stuff. LinkedIn recruiters actually put effort in their greeting messages. It rules. I'm just bragging at this point. Stop me.

Now, despite all this you may have noticed I'm missing a lot of things from my intro to an engineering career.

I'm not really sure how functions map to mathematical constructs. I actually dropped out of maths when we started doing that algebra where instead of equality you deal with stuff like 2*n > x/3 and you have to find out what range n and x are (I have no idea if this particular one is solvable, I just came up with it)

I'm still just wrapping my head around the more complicated types you can do in stuff like typescript. For what is worth I don't use types in personal projects. I think they are good for making code self documenting and thus, good for teams. Too abstract though.

For a long time I never used any real frameworks for web development. I totally slid past the angular and ember era because I considered unacceptable to have a site not work without JS enabled. Writing your entire frontend in javascript felt incredibly unnecessary when we have semantic HTML.

![](https://thepracticaldev.s3.amazonaws.com/i/l2ejqlhzv58drpkmu5ep.jpg)

3.

I love React. I love React because I know enough about scaling up HTML and CSS that I understand the value of single file components. I like the way CSS-in-JS gives you the enough abstraction to still use tricks like blind owl selectors while also giving you the full power of using JS to do stuff like container queries. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.

I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.

But what I hate the most about React is that it paves over the land of HTML, CSS, and JS progressively layering on top of each other and replaces it with 'efficient' and 'clean' code.
Compared to vanilla HTML it's very easy to add type checking to a React app to really make sure you can't accidentally add "12" + "8" because how else would you know you aren't getting 20 here. By running your app? Absurd. It's also very easy to automate tests by taking component snapshots and effectively freezing them in time, evolving CSS layouts be dammed. With CSS-in-JS you can ignore those pesky CSS behaviours like the cascade. It's not like it's the first letter in the name or anything.
Not having that much first class DOM manipulation and a mandatory build step anyway means engineers can finally start paving over the ugly duckling and liability that is javascript for other languages, based on the purity and elegance of mathematics, like Elm or Reason.

Some people think these are good things. Other people think they are a masturbatory exercise in service of nerds finding actually coding websites too boring and needing to spice it up.

![](https://thepracticaldev.s3.amazonaws.com/i/4d74ecz0wvl2qx4fiu1x.jpg)

4.

I'm a surprisingly fast learner. I have caught up. I know my stuff around all this shit. I'm also a bit of a rarity. The best frontend developers I know are at a complete loss right now.

Most modern frontend codebases are no longer about HTML and CSS. In fact they are so far removed from it that the idk 20? people total who still care about HTML and CSS and can code websites and haven't become product designers or whatever have no clue where to even start.

Our 'clean' and 'elegant' frontends are now often more clean in the back than in the front now. Our perfectly typed 20 file redux store supporting a form that doesn't work with javascript off. Our CSS-in-JS modules with typed props hiding spaghetti CSS with completely static props as an implementation detail.

We are building toilets with world-class plumbing that people can't then sit on. And the people who know how to fix the toilets have no clue how to fit a toilet into our plumbing.

The designer that knows CSS can't update some colours in GitHub without breaking half of the tests. The Product manager can't replace a bunch of words in a page without figuring out the PropTypes of the map component. The accessibility expert can't replace divs with buttons because the visual regression testing says that Opera mini in Windows Phone 6.5 renders a border about them and we can't merge changes until it all goes green. The frontend dev can't implement an accordion (honestly, that one might be for the best) because the guy who's super into types won't let her store state outside of redux.

In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.

![](https://thepracticaldev.s3.amazonaws.com/i/j9bo057dlq3hm1t189a9.png)

5

I think a lot about how I started coding. About how I developed an understanding of the web. It was wild. I didn't touch code for ages while still making cool websites. We just made things work.
The web, by design, always has had a bit of 'best effort' sprinkled all over it. You would make your HTML accessible and semantic and then write your CSS in a resilient way so when it inevitably breaks in a different/older browser the page still works. And then you sprinkle your javascript on top and if it doesn't work? That's fine because it's not required to function. It's icing on the cake.

I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.

![](https://thepracticaldev.s3.amazonaws.com/i/pmbz29o37bmccm191j67.png)

I picked up React Native as a web developer and here's what I've learned

Laura buns — Sun, 09 Jun 2019 13:43:09 +0000

For the last couple weeks, I've been building a React native app at work. It's a news reader (duh) and a bit of a monster at that, with filesystem access, background downloads, and push notifications.

This wasn't my first time using React but!! It was my first time using RN. Which is scary because new things are scary. It's been a great experience though, and I'm kinda waiting for an 'OH S**T' moment where something unexpected goes horribly wrong – but so far it's been ridiculously fun.

Why React native? Well, my team originally wanted a web app! (a PWA, they are all the rage now) We changed course for three key reasons:

Despite web being a 'nice to have' our first market was app stores
We wanted it to have very elaborate offline & background functionality. This is very early & experimental on web but a solved issue on mobile apps since day one.
We wanted to deliver a native-like experience. Think 60fps animations, multiple stacked views, the works. These are solved problems in the app world too but on the web we are on our own.
With react-native-web we have a path to turn this back into a PWA if needed

It's not the web

On the web, plain React eventually generates an HTML-based website. This is how you can use CSS and directly call DOM functions on your components.

Native is a bit of a different beast. Despite using React's syntax – and unlike libraries like Cordova – RN never gives you HTML, or DOM Elements or CSS, but rather orchestrates native views directly on your mobile OS. This is pretty awesome because it means your UI is truly native. Sure, it's being assembled on the fly using javascript but it's using the same set of blocks the rest of apps are using.

How different is this from standard React? Not a lot to be honest. The primitives are pretty similar!


/*react web*/
const Counter () => (
    <div className='row'>
        <button onClick={setCount(c=>c+1)}>Add number</button>
        <span>{count}</span>
    </div>
)

/*react native*/
const Counter () => (
    <View style={styles.row}>
        <Button onClick={setCount(c=>c+1)}>Add number</Button>
        <Text>{count}</Text>
    </View>
)

Using native UI not only makes your app a better citizen but also it's, like, fast. If you are used to struggling to get 60 fps animations on the web this is a whole new world where you just get that. For free! even on old as heck devices! (More on performance in a second part)

By the way! You don't get all the semantic element niceness from HTML5 in here either. Almost everything in RN is a View. This means it's super important to mark up the semantic purpose of your views for a11y purposes. You can use accessibilityRole to do that. If you need alt text, accessibilityLabel has you covered.

Getting started

I had some incredibly basic Xcode experience from doing prototypes eons ago (back then xcode looked like itunes? it was a weird time) but anyway I kinda knew what to expect compared to the web – faster apps, but a slower dev cycle with harder to use devtools.

_
i
was
so
wrong
_

First of all, if you just wanna dip your toes in the native waters you don't need any of this, you can use expo to run your javascript and handle all the app-y bits. This gives you significantly less control over the app bits on your app but what's pretty cool is that all your code is still vanilla React. If you ever need that control you can just expo eject at any point and get your raw Xcode and android studio projects.

Even after you eject, you still won't be using Xcode or Android studio for the most part (unless you wanna). react-native run-ios will fire up a simulated iPhone X and run your app, and react-native run-android will install it directly to your phone that you only meant to charge but it's fine I guess now you've got an app on your phone.

The react docs on setting up Android Studio are pretty good. When it comes to iOS, code signing your app is a bit of a pain – you need to do this before running it on a iOS device. You don't need to be a paid member of the apple developer program to do this but you need to be signed in into Xcode. What i normally do is try to compile it, click on everything red, and click the 'Fix issue' buttons until there are no more issues.

Finally, when running your app you can shake your device or simulator to get a pretty cool debug menu. You can hot reload code just like on the web, run the chrome devtools to hunt for bugs, or even open up the worlds cutest little inspector:

Styling

You will probably want to style your app. Unless you are making a todo list or whatever you will probably want to style your app a lot.

React native comes with a built in StyleSheet module. it handles styling for you. This rules because you don't have to argue ever again about what css-in-js solution to use. It's also bad because StyleSheet is so similar to CSS you might think you are writing CSS but the similarities are only surface deep.

const styles = StyleSheet.create({
    button: {
        borderRadius: 999,
        backgroundColor: 'tomato',
        padding: 10,
        paddingHorizontal: 10,
    },
    text: {
        textTransform: 'uppercase',
    },
})

const Button = ({ children, ...props }) => {
    return (
        <Touchable {...props}>
            <View style={styles.button}>
                <Text style={styles.text}>{children}</Text>
            </View>
        </Touchable>
    )
}

The built in documentation on how to style things is very good but I wanna get into the big changes first

It's pretty much like css-in-js

Your styles are a javascript object with camelcase properties. If you have used emotion or styled-components you'll feel right at home with this way of working

Chonky pixels

Most phone screens are pretty dense and scale up their UI so, as a unit, 1px is a lot and pretty big looking for borders. You can use StyleSheet.hairlineWidth to get the size of 1 screen pixel across devices.

But everything is a flexbox

Since all StyleSheet does is talk to the underlying OS you are restricted in ways you can layout compared to CSS. If you want to float something (For example to wrap an image to the side of some text) you are completely out of luck. Same goes for using CSS grid!

You have a magical flex property that consolidates flexGrow, flexShrink and flexBasis into a single number. I have no idea how to use this. @NikkitaFTW calls it 'backwards flex'. She has no idea how to use it either.

So you can't float things

Ours is quite a special case but since our app had to render very type-heavy articles. To fix this we decided to render the body of the article in a webview and put that inside our React native app. This felt wrong and counter intuitive since "it's all javascript anyway" but it's important to always use the best tool for the job and the web was built to render documents!

Or debug layouts 😰

Remember when you had to start coloring divs red to see where your layout had issues? Get ready for some NOSTALGIA. RN does offer a built in inspector but because it's inside the simulator (or inside your phone) it's kind of a hassle to use.

And there's no cascade or selectors

You apply your styles directly to your components. You can't style children based on their type or have things like hover or disabled states or :before / :after pseuds.

This sounds super limiting but in reality having a well architected and modular app with small components will take care of a lot of this for you.

None of your styles cascade, this can make your CSS more predictable but also a bit of a pain. We remediated this by using react context to encapsulate style properties we wanted to cascade down like theme colors. Context is ideal for this because you can have multiple contexts in the same screen for different nodes, almost working like css variables.

This is a bit of an oversimplification (we've got a useAppearance() hook that returns the values directly) but you get the idea:

/*
in your appearance file
*/
export const appearances = {
    dark: {
        backgroundColor:'#000',
        color: '#fff',
    },
    light: {
        backgroundColor:'#fff',
        color: '#000',
    },
}
export const AppearanceContext = createContext('light') // <- that's the default!


/*
in your view
*/
<AppearanceContext.Provider value={'dark'}>
    <Button>I'm dark!</Button>
</AppearanceContext.Provider>
<AppearanceContext.Provider value={'light'}>
    <Button>I'm light!</Button>
</AppearanceContext.Provider>


/*
in your component
*/
(...) => {
    const { backgroundColor, color } = appearances[useContext(AppearanceContext)]
    return (
        <View style={{backgroundColor, color}}>{children}</View>
    )
}

The loss of the cascade is not that big of a deal as it might seem except for a single but very important use case:

Text

All text you want to render in React native has to be <Text>Wrapped in a text tag</Text> and it will display in the system font at 16px.

You can of course style your text to have any font and size you wanna, but text comes so many shapes and sizes that you should be prepared to have a ton of variations. In our app we ended up having a single file for all our styled text elements but I'm not sure this is the best structure.

When it comes to fonts you'll probably wanna use custom fonts! Especially now that all apps are white on black with a bunch of lines and there is literally no other way than type to tell them apart. Good news first, you don't have to deal with @font-face rules which is pretty neat!

Sadly everything else is pain. Your fonts will live duplicated inside your Android and iOS projects and here's where it gets hairy: To use a font in Android you will reference its filename, to use it on iOS you will reference its Postscript name. Don't know what that is? Don't worry, I didn't either. It's this thing:

Images & icons

If you are following modern design trends most of your images by now will be flat vector images, probably inline SVGs and boy do I have bad news for you: You don't get to use normal SVGs in React native. They are not supported by the <Image/> element. This is bad especially for icons and such. How do you load images then? There's a couple strategies:

For complex shapes and such you can convert them into bitmaps, 90s style. You'll probably wanna set up a build pipeline to churn them out for you. All the assets in your app will be downloaded upfront so file size is not as big of a critical consideration as it is on web (but don't go bananas!) To make sure bitmaps are crispy you will want to export them at @3x their intended size on screen.

If you want to remotely import SVG that's a bit trickier but not impossible! There are several libraries that will do this for you by essentially chucking them in a webview.

For everything else (I'm doing this!) You can use react-native svg to use SVGs inside your code. The way this works is it exports React native versions of everything in an svg and you can use these and it draws the proper views for you

Having SVGs be first class citizens in React with props and animation and everything has changed the way i see all SVGs. i always knew they were markup but having to directly adjust them myself now has given me lots of ideas for cool things I can do with them.

At the end of the day react-native svg is a very elaborate hack that gives you views so it can also be used as a low level drawing library for things like lines and circles and whatnot! Your imagination is the limit!

A good way to assess what image loading strategy to use is by asking yourself how messed up will things be if this doesn't load? so for example you might want icons to be inline SVGs but big hero images to be remotely downloaded. Be aware that some things will always be messed up and that some of your users will never see images anyway because they use screen readers or have poor eyesight or they just can't figure out what an arrow coming out of a box in a circle is supposed to mean.

Always make sure you have proper accessible descriptors for all your images! And provide sensible fallbacks if an image can't load (For example, in a hero, code in a background color that gives the text enough contrast)

Navigation

react-navigation kinda sounds like the react-router of this land. You might have noticed that mobile apps have more advanced navigation types than the web. You can't just replace things in place and call it a div, if you look at any mobile app, all your screens slide out and in and away. react-navigation has a data model that is super linked to these transitions.

Each navigator is a flat list of screens with an entry point and each defines the transitions between its screens. For example you can use a single navigator for all your app and all your screens within it will do that thing where they progressively pile on top of each other from left to right.

export const RootNavigator = createAppContainer(
    createStackNavigator({
        Main: HomeScreen,
        Downloads: DownloadScreen,
        Settings: SettingsScreen,
    })
)

But say you are doing a music player and you wanna add a card that can slide over any views with some "now playing" info. You can just create a new top level navigator that contains your original navigator and that lonesome card. You can even just use {mode: 'modal'} on it to get a pre made animation and voila, now if you navigate to your now playing view it glides over the rest of your app!

export const RootNavigator = createAppContainer(
    createStackNavigator({
        Main:   createStackNavigator({
            Main: HomeScreen,
            Downloads: DownloadScreen,
            Settings: SettingsScreen,
        }),
        NowPlaying: NowPlayingScreen,
    },
    {
        mode: 'modal'
    }
)

Something really cool is that even though your navigators are in a hierarchy your route names aren't. You can navigate from any route to any route without worrying about reaching out to the top level or something. It just works™.

For accessibility reasons you will probably want to use <Link /> like this. This will make things neat and tidy if you ever make a website with react-native-web

Good to know! react-navigation gives you a lot of control but in exchange it recreates a lot of the platform's native navigation views. If you have simpler needs you might wanna look at react-native-navigation which implements the platform native navigation bars at the cost of flexibility.

To sum up

The only bad thing I can say about React native is that it's too good? As I said at first I'm still waiting for a major 'oh no' type moment where I rode a wrong assumption for far too long and half of the app is broken or something.

Funnily enough this happened with my first React (web) app! We got a last minute requirement to make it work on Samsung Internet on low end phones and well, it was a Redux and websocket fueled beast, best we could do was getting it to crash at the signin screen instead of at the splash page.

IMO RN is pretty good and I feel sometimes it can get a bit of unfair flak. Web developers fear it because it's not the web and app developers fear it because it's an unnecessary abstraction. Personally I'm hella impressed at how elegant it is as a solution to write multi platform apps that feel like they belong on each platform. I'm also super excited about eventually using react-native-web to go full circle and get a PWA!

🥳

Crossing fingers this was interesting to read! There are parts of this that I feel I could turn into a full blown book!! I'd love to hear your thoughts on what you found odd or funny in React native and I hope this post inspires you to start making apps!

Did you enjoy this post? Pls let me know! I wanna publish a followup with even more things like animation and perf but I don't wanna bore the world with my React native ramblings.

psss. you can follow me on twitter @freezydorito