DEV Community: alanmynah

Learn Command Line

alanmynah — Wed, 28 Jul 2021 17:08:43 +0000

This is a cheat-sheet to go along with the stream I did on Scrimba YouTube channel about command line.

Command Line notes

Where am i? What's here? How do i console.log?

pwd
ls
echo 'hello Scrimba!'

CRU(M)D

# create
mkdir cmd-session
cd cmd-session
touch script.sh

mkdir sub-folder

# read
ls sub-folder
cat script.sh

# move/update
mv script.sh sub-folder/script.sh
mv script.sh new-name-new-file.sh

# delete
rm script.sh
rm -rf sub-folder

Execute

Create a script.sh, example:

# touch script.sh, open it and write something like:
echo "hello, running script!"
echo "where am i?"
pwd
echo "ok, let's go somewhere else!"
cd /code
pwd
echo "that's better"

To execute a script:

./script.sh

### oh no, permission denied! what now?

Permissions

# see permissions
ls -l
# they are repeated, 3 times, for user (owner of the file), group of users, everyone else.
# -rwx - read, write, execute
# to change permissions
chmod u+x ./script.sh

Alias

alias script='~/script.sh'
# is this an alias?
type script

Getting help and Man pages

node --help # -- is how you indicate a flag, -h is a shorthand, so node -h is the same.

For linux's own utilities, --help wouldn't work, so they have man manual command.

man ls

For a more visually pleasant man pages:
https://explainshell.com/

Bonus: Search

grep 'echo' ./script.sh

grep '<body>' ./
# grep: ./: Is a directory error, so you need to add recursive flag to search through directories
grep -r '<body>' ./

Github from scratch

alanmynah — Wed, 02 Jun 2021 17:46:57 +0000

This is a cheat-sheet to go along with the stream I did on Scrimba YouTube channel about git and GitHub.

I've recently gone on a Scrimba Livestream to talk about git and Github. I love simple workflows with git and this is my cheat-sheet to use. Feel free to hit me up on twitter or Scrimba Discord if you have any questions. Also if you spot something not right, raise a PR 😉. (Details below)

Contributing to a repo

Pick a repo, fork it (optional) and clone it.

Alternatively, create a new one.

# replace the below URL with the repo in your account that you want to work with
git clone https://github.com/alanmynah/alanmynahdotcom.git

Then just follow Branching steps

Branching

# create a new branch and switch to it
git checkout -b new-branch
# connect the local new branch to the remote counter part
git push --set-upstream origin new-branch

Now follow the steps in My daily workflow

My daily workflow

# add all the files
git add .
# commit
# tips on helpful commit messages:
# https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/
git commit -m "type: brief description (<50 chars) of work done"
# push
git push

After a few commits, raise a PR.

When done, don't forget to Pull after a PR

Pull after a PR

git status # should be on the branch
git checkout main
git pull

Then pick a new feature and create new branch as described in Branching section

Creating a repo

Create a repository locally (like via CRA), go to github.com, create a repository via UI.

Copy and paste the steps from the outline in …or push an existing repository from the command line.

These are the steps:

create-react-app my-blog
# these are pasted from `…or push an existing repository from the command line` section when new repo is created.
git remote add origin https://github.com/alanmynah/my-blog.git
git branch -M main
git push -u origin main

Remote vs office or the importance of having a choice.

alanmynah — Fri, 12 Mar 2021 09:06:45 +0000

Photo by visuals on Unsplash

I started following my take on three strikes rules, where if I want to rant about something for 3 consecutive times, I need to sit down and have a cool-headed think about why it winds me up so much.

Remote vs office has been on my mind way more than 3 times. But really what prompted this post is that someone I work with said (words to that effect, this is off my memory here): "I like and want to work from the office, but I'm made to feel as if it's something bad." And you know what? Despite me not sharing the desire for office work, I sympathise with the sentiment that no one should feel bad for having a preference.

I know where this is going

Before you jump to any conclusions, yes, I love working remotely and I hope we (those of us who want) continue. But when we have a chance to reopen, we should not go back to the mirror image of what we had before the pandemic.

Just imagine. Working from the office one day a week is a massive perk. You are allowed to get it after probation and it would involve a contractual change 😛. Those who wish to work from offices on a more permanent basis, say 2-4 days a week, are essentially forced to haggle and sacrifice some of their salary for the privilege. Yep, the reverse was a real story, I once heard a dev from Cambridge tell me.

Where is a downvote button here?

I can see where the anger towards 'going back' is coming from. I really do. From encouragement by the gov't, to pretty much a property developer fessing up that they'd lose a tonne of money if we don't, but covering their primary motive up with concerns about 'fatigue' and convenience of doing "life's admin". As if people can't do it at the local high street. Unless you live at Canary Wharf, in which case my commiserations. There are very few places that I'd compare in soullessness to concrete barracks of my native Dnipropetrovsk, but there you are.

People are also fatigued for a multitude of reasons that have pretty much everything to do with the pandemic and not having a choice.

Are there benefits to working from home?

No commute? Saving HOURS daily? Yep.
Easier to focus? Aha.
More and hopefully better sleep? 💯
Saving some cash on petrol, insurance, train tickets? Oh yes!
Supporting local trade not just at the weekend? Hey, no prizes for guessing where I will be buying my coffee when the local places finally open up.
Saving some money on not eating out during work lunches? Erm, sure, but not after things open again 😆
Climate change? Yeah, I hope so anyway. Yes, yes, I know, I heat my house too, but I don't have 5m tall ceilings, and it's much easier to control one room in the house, instead of an open-plan office. But if you live in a converted church, scratch that one out.
Seeing your kids and family more? Definitely! Some of you must have this funny smile on your face, thinking "I bet he doesn't have kids after reading that" and you would be 100% right, Sherlock. But think about it, they'd have been at school now while you're reading this; your home office filled with silence. And during holidays you'd have been gone to someplace sunny or snowy, whichever you prefer. But you can't. See, that 'no choice' thing again?

We were told it's not possible

So all these people that are like me that love working from home are somewhat anxious that this might not last. Previously we were told that "we need to have a discussion and kick off trials", "we're not sure how productivity might be affected" (this one deserves a separate rant, but not 3 strikes yet), and "it would require some investment into home setups and we don't have a budget for that yet (aka, will never have, 😉-😉)" and then BAM! over the next couple of days and some painful MS Teams installs later, it's now come to life. Although, let's be honest, for most, we just brought our laptop home. Soooo it is possible and judging by the emails I received and had some forwarded to me, everyone's CEOs are telling us what a great job we did! 🥳🎉🎊

Yes, yes, ok, some places were pretty strict with confidential information policies and static IP access to production, possibly some dev infrastructure hosted in-house with access only over the local network. Now as I've caveated the 'well-actually' 1%, how many of you from the 99% were told straight up "we have an easy choice between office or remote, do as you please"? Some of us were in a truly bizarre situation, where you had to come to the office to work closely with a remote team in a different timezone! But WFH was a perk...

No better problems to write about?

What was that? Did I just hear "really, aren't there bigger problems in the world?" Ok, glad to have the relativists in the room too! Absolutely there are. Which one of the problems of the world do you care about the most? Oh, that's an important one, sure, we definitely need to do something about it. Hey, I can relate. We can focus on problems that we think we can do something about. And mine is to convince people to be more considerate when creating reformed workplaces.

During any of the remote vs office conversations, I keep remembering this graffiti, which is rather applicable to a lot of conversations in general, but this one in particular.

So yeah, remote defenders, I get your point. See? I'm your man, I feel you and share your concerns. Due to a really strange set of circumstances we've got what we were always told is difficult or impossible to get. It appeared to be relatively easy too. And that left a bitter aftertaste in some of us. We didn't have a choice. Now the tables have turned and it feels like someone wants to take it away, back to what it was before.

What do you want then?

Moving forward, do we really want to be denying the choice to people who we work with?

Some of your co-workers LOVE to be in the office. Just as they were oblivious to how much you want to work from home, we were oblivious to how much they actually enjoy the office. It had downsides, but it was their preferred status quo. Why bang on about how much they love it?

Any perks to the office?

Personal conversations
Getting to know people a bit better
Listening to all the amazing books, and podcasts, and all the music on your commute?
Easier meetings (double-edged sword)
Getting together with them to celebrate.

And I know, I know, you like some of these too and the pandemic prevented you from seeing relatives and loved ones. You too want to catch up with people, but just don't value what the office has to offer over WFH. And that's ok!

Someone once said: "This pandemic has flipped the world, where extroverts were able to finally see how excruciating it must have been to introverts."

Drawing parallels, do we 'remotists' really want to torture 'officers'?

The future is distributed and it's really for your company to figure out how often all of you get together. Yes, ok, in our tribe, attitudes to Christmas parties range from 'hate them' to 'can barely stand them'. But hey, we can all remember some great stories, so getting together is ok, sometimes.

We must promote and advocate for the ability of our fellow co-workers to come to the office whenever they want or please. Just not drag us along.

We need to be able to have a choice

We all want to have a choice. Regardless of what the news outlets, property developers, or even your boss think.

Make your views known, your company should know where everyone stands. Don't send that thrashing tweet about how blissful and perfect WFH is and that heretics should be disavowed from WFH paradise. Simply don't be an arse, your co-workers will thank you. And hopefully, they will stand your corner for your ability to have a choice when your company thinks about getting you a season ticket loan again.

Top 3 programming languages to learn in 2021.

alanmynah — Thu, 31 Dec 2020 13:03:31 +0000

`JavaScript`

More like "still everywhere". I said so 3 years ago and it was already common knowledge, now even more people know about it. "The Sun rises in the East" type of statement. Some were happy, some were not, but now JS has evolved, TypeScript got more popular, we got Deno, the march goes on, and so the language is still the lingua franca of programming: mobile, web, backend, desktop apps, ML/AI, you name it, you can probably create it with JS.

Learning materials have become even better than they were, so compared to other programming languages, ease of learning, and finding help, JS is still firmly at the top spot. Content creators have stepped up their game and introduced new courses. There is soooo much high-quality material for free on YouTube and paid content is out of this world.

Closest to my heart would be Scrimba's Frontend Developer Career Path. Simply because of how comprehensive the content is and it can easily be the core stop to get a job. The Discord community is great and it's amazing seeing how people learn and get their first jobs in the industry. I loved being involved in curating materials with my wife for the career-path, reviewing courses, and helping out the core team. </humble-brag>.

What more can I say? If you're not sure what interests you most, your friends or the web hasn't sold you on anything in particular, definitely learn JS. It's a win-win bet.

`C#`

Ok, I am biased here too. C# is what I write in my daily job. So no surprises, of course, I'd recommend people learn it. The learning curve is a bit steeper, it needs some initial setup, but it just jumped ahead in the last 3 years. With the latest .NET 5, you can write code with almost no boilerplate and you can use C# everywhere: mobile, backend, frontend, ML/AI, cloud apps, desktop apps. And if with JS you kinda know that you can create all of it, with C# you've got a guarantee from Microsoft that you can.

For newcomers, it might be tricky to get familiar with .NET ecosystem as it's a very curious mix of old and new, but Scott Hanselman has a really nice video to clarify everything.

One of the JS's downsides is that things move too fast and the ecosystem is volatile, C# is the opposite. You can very safely build something and forget about it for decades, which is why if you want to get a job at a bank, but Java makes you sick - C# is your go-to.

The demand is for C# devs is high and it's pretty pleasant to work with.

`Elixir`

Ok, so I hope this pick caught you by surprise. Elixir is definitely gaining a lot of popularity and it's 100% deserved. Why? Possibly because it's the most useful from the easiest to learn functional languages; or maybe because functional programming (FP) is trendy and hype and Elixir is a pleasure to learn; or maybe because most Ruby devs now switch to Elixir in droves (creator of Elixir used to be a Ruby on Rails dev).

Think of it as FP's Python or Ruby - friendly and helpful, won't bite your hand off if you make a mistake - error messages in Elixir are just heavenly and very helpful; "Let it crash" attitude is not novel, but definitely rare in the industry; the docs are amazing and learning it as a 2nd, 3rd and so on language just feels familiar.

Elixir runs on ErlangVM and has an astonishing foundation. I will leave the amazing reasons why you should learn it to someone who's got production experience in it, taken from here:

Is fun and easy to use
Has the ability to meet modern user demands
Has a rewarding career progression
Has an active and supportive community
Has a range of helpful tooling
Has frameworks to allow full-stack development
Has easily accessible documentation
Ensures you grow as a programmer.

Elixir has a surprising level of maturity to its ecosystem, and feels 29 years old and not 9. Built-in best practices will ensure that even if you're starting your programming journey with Elixir you will not regret your choice.

5 Whys, how to use it correctly?

alanmynah — Tue, 29 Dec 2020 18:41:11 +0000

Photo by Birmingham Museums Trust on Unsplash

Intro

This article is most definitely going to be a part of a larger series on how we, software engineers, are misusing manufacturing practices, techniques and tools, and then complain that they are broken, unfit for purpose, or just wrong.

TL; DR

The 5 whys in the original sense is an effective technique that should most definitely be used. Any shortly named heuristic that is then explained in 1-2 sentences is most likely going to miss the most fundamental reasons for its existence. Please don't use it to solve complex problems, but do apply it to finding problems in your CI/CD pipeline or finding some simple bugs.

Why 5 Whys don't work

As THE tool for root cause analysis, 5 Whys is a rather discredited technique. Many very good articles and overviews have been written. This one by John Allspaw, at least in my twitterverse, is quoted most; and sums it best with:

for complex systems: there is no root cause.

Props also go to Mark Mulvey for writing one of the really succinct breakdowns of the problem with 5 Whys. That was in turn inspired by 5 Whys topping Swyx's list of Naked emperors in Tech.

But the cherry on top is placed by Teruyuki Minoura, Toyota's own former managing director of global purchasing, who described 5 Whys as being

too basic a tool to analyze root causes to the depth that is needed to ensure that they are fixed.

Why the criticism is misdirected

Because it's a straightforward simple tool, that is good only for a small set of simple causes.

Complex systems are not within the scope of this tool. It's just A tool for root cause analysis (RCA), and a simple one at that, for the exact reasons described in the section above.

Just to be clear, all these criticisms are valid, but it really should be directed towards how 5 Whys is 'marketed' or more importantly, interpreted. Seriously, google it to see what I mean. The first hit will come from Mind Tools article that describes it as

The method is remarkably simple: when a problem occurs, you drill down to its root cause by asking "Why?" five times.

and

This simple technique, however, can often direct you quickly to the root cause of a problem.

Even worse, AWS's Root Cause Analysis (RCA) page simply states

Identify Root Causes: Use Five whys and Ishikawa diagrams

Origins and present day

The birthplace of the technique is somewhere on the Toyota's shop floor, but it really took off after Taiichi Ohno, the father of Toyota Production System (TPS) wrote his book titled TPS. Beyond Large-Scale Production. He mentioned the technique once. Yep, didn't dedicate chapters to it and didn't even bother to warn anyone of misusing it. And based on Minoura's thoughts on the matter, I can guarantee, there was a lot of it even at Toyota.

Simple sounding techniques have a tendency to turn into holy wars about their true meaning (looking at you TDD and OOP).

Anyway, back to Taiichi Ohno's passage:

Repeating why five times, [...], can help uncover the root problem and correct it. If this procedure were not carried through, one might simply replace the fuse or the pump shaft. In that case, the problem would recur within a few months.

Note, that the focus is on questioning the fault, rather than ignoring it. It's a guidance for manufacturing processes at an assembly line. Production is moving and ignoring a problem might never have any repercussions for you as a worker, while raising alarm risks a lot of delays and oftentimes jeopardizes your throughput dependant income too.

Ohno then goes to say:

To tell the truth, the Toyota production system has been built on the practice and evolution of this scientific approach. By asking why five times and answering it each time, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms.

So "dig deeper, don't stop at the first opportunity.", got it. And he then finishes with:

In a production plant operation, data are highly regarded - but I consider facts to be even more important. When a problem arises, if our search for the cause is not thorough, the actions taken can be out of focus. This is why we repeatedly ask why. This is the scientific basis of the Toyota system.

That's it. It appears that his understanding of 5 Whys is that it's just a shorthand for 'be scientific in your approach to problem-solving'. He does not mention the technique in his book anymore. Why? Because it's insignificant compared to the much more important, structural, and cultural techniques in TPS, like Jidoka.

What is it good for then?

It's a useful rule of thumb, to avoid sweeping problems under the rug. Flaky tests? Why? Flaky pipeline? Why?

It is a way to try to get to a set of countermeasures to prevent the defect OR be able to spot the defect so early as to absolutely minimize the cost (material, time, and other) of the defect to the manufacturing process.

And don't get hung up on the magic number 5. I bet it was called like that because, in Japanese, it sounded better than 4 whys or 7 whys - a surprisingly common reason to do a lot of things in manufacturing.

Finding why you get that undefined error (Well, in about 50% of cases 😜), why CI failed, and even throw some API error codes at 5 Whys and it will help you out. Other than that, just use the technique to get yourself started and pick up something more advanced.

The alternatives

There isn't a single technique that would work universally, but here are some that might help you (Yes, 5 Whys is one of them, so skipping it):

Feel free to PR this article with your favourite one.

Closing thoughts

IMO, these misunderstandings stem from our (those working in the software industry) inability to transfer context. Manufacturing is geared towards repeatable, quantifiable, plannable processes. Software development, more often than not, isn't. Applying solutions to the wrong context produces unexpected results.

One thing you can take away from this article is this sassy quote for your internal slack.

Tired: 5 whys is rubbish and 'in complex systems, there is no root cause'

Wired: let's expand the RCA docs with more advanced 6-sigma techniques.

What is an API? Explained in plain English

alanmynah — Mon, 02 Nov 2020 17:41:54 +0000

Photo by Kate Townsend on Unsplash

What exactly is an API?

Any aspiring developer, product(project) manager new to the software industry, eventually gets hit with the term API and when questioned about the exact meaning of this acronym, encounters a lot of hand-waving and generic statements. Add all sorts of metaphors about waiters, beers (possibly because it makes people think of IPA), and waiters bringing your unwilling teacher's favourite beverages.

API stands for - Application Programming Interface

Officially, API stands for - Application Programming Interface, but that doesn't clarify anything, does it? Otherwise, you wouldn't be reading this.

Start from `UI`

Let's start from some solid ground. When you go to any website, you see a collection of buttons, links, dropdowns, text fields, and date pickers. As a whole, it is a way for us, users, to interact with the system.

User Interfaces are for us, users, to interact with systems.

We say it's a User Interface. Netflix has one, when you go to watch a film on your laptop, you use a keyboard and a mouse to interact with the UI. On your TV, it's a clunky remote. And on your phone, you use your fingers to tap on the screen.

Some cars have stereos that get operated with knobs and buttons and more modern versions have touchscreens. All of these are User Interfaces.

`UI` is a gateway into `API`

APIs are ways for us, developers, to interact with programs.

Application Programming Interfaces, are for us, developers, to interact with systems.

Users interact with UIs that developers wrote by interacting with APIs that other (or same) developers created.

Developers write programs that expose some interactive points for others to use.

Why create API?

I can sense a question: "Why to create a program to interact with another program that does what I want? Why not have one?"

UIs only care about creating a pretty, intuitive, and safe environment for your users to access the services you provide.

APIs only care about providing access to these services in a secure, consistent, and reasonably fast manner.

Mixing the two is possible, but the industry found that separating concerns is a pretty good idea.

Summary

API is simply a catch-all term for interaction points exposed by one program for developers to use to create their own.

The reason for such monumental confusion is because the term 'API' is oftentimes used proverbially and sometimes as a replacement for words like 'system', 'services', 'backend', or your companies moniker, like 'the beast', 'monster', 'flake', etc.

Hope this clears things up and if you've still got some questions, feel free to get in touch!

Use Nobel Prize-winning Auction Theory to choose the right job offer

alanmynah — Tue, 27 Oct 2020 18:27:38 +0000

Nobel Prize Idea

So it recently did the rounds in the news - Nobel Prize in Economics was awarded to Paul Milgrom and Robert Wilson for their work on auction theory.

Nobel: US auction theorists win Economics Prize - BBC News

What is Auction Theory?

Milgrom and Wilson’s research focused on “unknown common values” - the value of a thing or a resource is the same for everyone, but no one is quite sure how much it’s worth, because they don’t know how much they can make out of the resource. They found that when this is the case, bidders tend to bid low to avoid the winner’s curse (overpay for something worth much less). If everyone bids low, the seller is sad.

Our friends, Milgrom and Wilson, thought of some formats that are designed to reduce the problem of “unknown common values”.

For example, use multiple rounds, and between each round, information about all the bids is revealed, so everyone knows what’s everyone bidding, so no one is afraid they are overbidding. The next round has a minimum bid of a maximum bid from the previous round. This is repeated until there is a clear winner. The seller gets top dollar, and the winner knows that what they are getting is well-valued by the other market participants.

Can devs use this for job offers?

Do I think candidates can get over the initial awkwardness of the notion and ditch the current best practices?

Maybe... Is anyone willing to start a spreadsheet with all their offers that they later email to everyone who offered them a job, until there is only one highest bidder?

In reality, this isn't any different from what we're doing now, but on a smaller scale and with individually crafted emails.

The negotiation phase of the offer is fraught with faux pas and one needs to be clued up on the matter to secure a decent package. I don’t even want to blame the companies for taking advantage of the inexperienced candidates, but it’s worth pointing out that it’s not uncommon to hear people complain that they were afraid to negotiate and as a result feel underpaid when they discover their peers’ pay rates.

Objections

Yes, compensation is complex, there is much more to it than just monetary reimbursement, but for this scenario please consider that the candidate evaluates the offer purely on £££ value, with all other things being equal.

Some notes and sources:

“Ok, still not quite sure, can you please ELI5?”

Sure thing, here’s reddit's ELI5

“Sorry, I don’t really like reading, do you have a podcast link or something?”

Sure, here’s the BBC’s More or Less episode explanation
BBC Radio 4 - More or Less: Behind the Stats, Auction Theory - Paul Milgrom and Robert Wilson

“Yeah, I don’t think I still have enough info, can you give the source to a proper explanation?”

Straight from the horse’s mouth: Paul Milgrom’s book on UCLA website

Would you try this?

I really want to hear your thoughts! I did make a survey on LinkedIn and it TANKED! Got 2 replies, so clearly not enough to be decisive. Please let me know what you think.

Hey! Thanks for reading! Questions, suggestions, feedback? Reach out on Twitter @alanmynah

Photo by 🇨🇭 Claudio Schwarz | @purzlbaum

Build an app to find your next meal with React Hooks

alanmynah — Mon, 27 Apr 2020 19:24:03 +0000

A quick React Hooks tutorial to get you started

In this tutorial, we will learn the basics of React hooks by building a recipe finder application.

The premise is straightforward, a user can type an ingredient and get 10 recipes that use the ingredient. Nice and simple.

What’s a hook?

If you are rolling your eyes 🙄, skip to the next section! 😛

According to the official docs:

A Hook is a special function that lets you “hook into” React features.

So in this post, we will learn useState, useEffect and how to create our own custom hooks. We will also cover how to fetch data from an API and some HTML-form management using hooks.

But as for now, let me hook you up with some new React features.

What will you need?

Maybe a tiny bit of JavaScript and some React knowledge about props, state and event handlers.

If you are completely new to React, that’s no problem, I can wait for 5 minutes while you’re reading this great 5-minute intro to React.

The setup

Not a huge fan of complicated setups. There are as many ways to set up React apps as there are React developers, so if you have a favourite setup, feel free to use it.

For this tutorial, here’s an HTML file which imports React and ReactDOM libraries via CDN using <script> tags:

Alternatively, you can also experiment with the code in this React Scrimba playground

Our Hooks Application

We are going to build a very simplified recipe finding app that we can use to start learning hooks. It will consist of a form with an input field and a submit button. We will fetch some recipes over Recipe Puppy API and display the results in an unordered list.

Find dinner ideas with Recipe Puppy API

To get some flavoursome ideas and to find something tasty, we will use Recipe Puppy API. Inside the <script> tag we have provided getData() helper function to fetch the recipes from the API.

For this tutorial, it’s best to think of it, like a slightly improved fetch() function and we will use it in the same way.

We didn’t really want to distract you from learning hooks, so we created this helper function do all the heavy lifting.

Read from an input field with useState hook

Let’s create a barebones layout. So far, an emoji for fun and a console.log as a tradition. Nothing overly complicated.

function App() {
  return (
    <div className="App">
      <h1>Amazing Recipes</h1>
      <input
        placeholder="Favourite food"
        onChange={(e) => console.log(e.target.value)}
        value=""
      />
      <button type="submit">
        <span>Find something tasty</span>
        <span role="img" aria-label="avocado">
          🥑
        </span>
      </button>
    </div>
  );
}

Now we would like to store the input value. If it were a class component, we would store data in this.state. Well, with hooks, we simply useState().

useState accepts initial state and always returns a pair of values: the current state, and a function that updates it.

We can access the returned pair using array destructuring in the very beginning of our function body, like so:

function App() {
  const [ingredients, setIngredients] = React.useState("");

  return (
    <div className="App">
      <h1>Amazing Recipes</h1>
      <input
        placeholder="type ingredients here"
        onChange={(e) => console.log(e.target.value)}
        value=""
      />
      <button type="submit">
        <span>Find something tasty</span>
        <span role="img" aria-label="avocado">
          🥑
        </span>
      </button>
    </div>
  );
}

In the snippet above, ingredients is initial value, we can use it as a value to display to our users.

setIngredients is a state update function for ingredients and can be added to events, in our case that’s onChange.

We pass an empty string "" as the initial value to useState(""), as if we wanted to simply say ingredients = ""

function App() {
  const [ingredients, setIngredients] = React.useState("");

  return (
    <div className="App">
      <h1>Amazing Recipes</h1>
      <input
        placeholder="type ingredients here"
        onChange={(e) => setIngredients(e.target.value)}
        value={ingredients}
      />
      <button type="submit">
        <span>Find something tasty</span>
        <span role="img" aria-label="avocado">
          🥑
        </span>
      </button>
    </div>
  );
}

So on the first render of the app, it would look as if nothing changed.

But if we type something into the input field we can see that our input gets updated as we type.

Fetch data from an API with useEffect

useEffect hook tells React that the component needs to do something after render. In our case, we want to get some recipes. To call the API, we will call getData() helper function and for now, we will pass an empty string "" to it.

We will also use another useState hook, to store our recipes.

    const [ingredients, setIngredients] = React.useState("");
    const [recipes, setRecipes] = React.useState([]);

    React.useEffect(async () => {
      const results = await getData("");
      setRecipes(results);
    }, []); *// <-- what's that? More on [] below*

    return(
        //...same JSX...
    );

Oops, we get a warning.

Luckily, the warning contains the solution and a helpful link to learn more.

useEffect(() => {
  const fetchRecipes = async () => {
    const results = await getData("");
    setRecipes(json.results);
  };
  fetchRecipes();
}, []);

You might have noticed an empty array [] as a second argument to useEffect. Why do we use it? useEffect runs after every render. If we pass some value into the array, we will ask useEffect to check if the value changed and apply the effect only if that value changed. We will do so when we pass [] we effectively say ‘Run useEffect on every render.’

Now, with the error gone, we can render out the recipes.

return (
  <div className="App">
    <h1>Amazing Recipes</h1>
    <input
      placeholder="type ingredients here"
      onChange={(e) => setIngredients(e.target.value)}
      value={ingredients}
    />
    <button type="submit">
      <span>Find something tasty</span>
      <span role="img" aria-label="avocado">
        🥑
      </span>
    </button>
    <ul>
      {recipes.map((recipe) => (
        <li key={recipe.title}>
          <img alt={recipe.title} src={recipe.thumbnail} />
          <a href={recipe.href} target="_blank" rel="noopener noreferrer">
            {recipe.title}
          </a>
        </li>
      ))}
    </ul>
  </div>
);

// more on target="_blank" rel="noopener noreferrer"
// can be found here: [https://mathiasbynens.github.io/rel-noopener/](https://mathiasbynens.github.io/rel-noopener/)

We can use a ternary expression to render a default image if there is no thumbnail image provided by the API.

<ul>
  {recipes.map((recipe) => (
    <li key={recipe.title}>
      {recipe.thumbnail ? (
        <img alt={recipe.title} src={recipe.thumbnail} />
      ) : (
        <img
          alt="default-meal"
          src="[http://i65.tinypic.com/maateu.png](http://i65.tinypic.com/maateu.png)"
        />
      )}

      <a href={recipe.href} target="_blank" rel="noopener noreferrer">
        <span>{recipe.title}</span>
      </a>
    </li>
  ))}
</ul>

Trigger a hook manually to fetch data

A good way of triggering a manual fetch would be with a form element. A form also makes it possible to trigger the button with “Enter” on the keyboard, which is a nice bonus.

Let’s write doFetch(). It will receive search parameters that getData() requires to call RecipePuppy API.

    const [ingredients, setIngredients] = React.useState("");
    const [recipes, setRecipes] = React.useState([]);
    const [search, setSearch] = React.useState("");

    useEffect(() => {
        const results = await getData(search);
        setRecipes(json.results);
      };
      fetchRecipes();
    }, [search]);

    const doFetch = query => {
      setSearch(query);
    };

Let’s now wrap our input and button in <form> and pass to onSubmit() event our doFetch() function, passing ingredients to it.

<form
  onSubmit={(e) => {
    doFetch(ingredients);
    // To prevent browser reloads when clicking the submit button
    e.preventDefault();
  }}
>
  <input
    placeholder="type ingredients here"
    onChange={(e) => setIngredients(e.target.value)}
    value={ingredients}
  />
  <button type="submit">Find something tasty</button>
</form>

Great, now it all works!

That’s the app done and let’s have a small refactor.

Create a custom hook

We can create our own hooks, by combining hooks that React gives us.

Let’s create our own hook by extracting search and recipes state hooks and doFetch(). We can also specify what a custom hook returns, by returning an object with variables and functions.

const useRecipePuppyApi = () => {
  const [recipes, setRecipes] = React.useState([]);
  const [search, setSearch] = React.useState("");

  useEffect(() => {
    const fetchRecipes = async () => {
      const results = await getData(search);
      setRecipes(json.results);
    };
    fetchRecipes();
  }, [search]);

  const doFetch = (query) => {
    setSearch(query);
  };

  return { recipes, doFetch };
};

Inside of our App component we do not need to change any JSX, as all that code needs are just recipes and doFetch.

    const useRecipePuppyApi = () => {
      // ...custom hook logic...
    };

    function App() {
      const [ingredients, setIngredients] = React.useState("");
      const { recipes, doFetch } = useRecipePuppyApi();

    return (
       // ...JSX is the same...
      );
    }

Now, this component is so nice and simple to read. It’s two hooks and JSX.

Congratulations. You now know the very fundamental hooks and even more importantly you also know how to create your own!

Full code

Continue learning React

I hope you’re hooked (yep, of course, there must be a pun), and you want to learn more, be sure to check out free React course on Scrimba. as I learnt most of this from there.

Create a neat RSVP card with pure CSS.

alanmynah — Fri, 23 Aug 2019 18:59:22 +0000

I've been one of the lucky few who had a preview of @KevinJPowell's responsive web developer bootcamp on Scrimba. I cannot recommend it highly enough, as watching the course helped me immensely in writing this post!

With this post, you will learn how to create an RSVP card, with just CSS and HTML, for any occasion!

Also, I have to admit that I've been a massive Scrimba fan for a very long time and always keep telling everyone I meet at every meetup how great it is!

Naturally, if you fancy playing with my code, there is a playground.

If English is not your native language, like me, and you have never encountered RSVP cards before, RSVP is French for Répondez s'il vous plaît, meaning "Please respond" and is used widely in the UK, US, Canada, etc. as invitations to weddings and other formal occasions.

Start with simple HTML

Let's start with HTML representation of the card and have separate divs for card's front and back.

<html>
  <head>
    <link rel="stylesheet" href="index.css" />
  </head>
  <body>
    <div class="container">
      <div class="card">
        <div class="front">
          <h1>Front</h1>
        </div>

        <div class="back">
          <h1>Back</h1>
        </div>
      </div>
    </div>
  </body>
</html>

Let's now add some basic CSS to prepare a container for where the card is going to be. We can use relative % units to make sure that everything is centred.

body {
  background: #b6d4df;
}

.container {
  position: absolute;
  background: none;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

Let's now add the card.

Percentage values are that of the parent container. So when we use width and height of 100% on .card class, it will take the same size as .container class.

body {
  background: #b6d4df;
}

.container {
  position: absolute;
  width: 60%;
  height: 60%;
  background: none;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

.card {
  position: relative;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

And we can now also add styles for each face of the card.

.front,
.back {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  text-align: center;
  border-radius: 15px;
  overflow: hidden;
  background: #fafafa;
  color: #333;
}

Well, the card is there, but we see the back of it. That's because back is rendered later, so it's covering front. To show front, I need to add backface-visibility: hidden; to both sides and now just need to rotate it.

.front,
.back {
  /* the rest of CSS */
  backface-visibility: hidden;
}

.back {
  transform: rotateY(180deg);
}

That's much better. Let's try to make it flip around when we hover over the card.

.card:hover {
  transform: rotateY(180deg);
}

We're getting there, but it's not what we quite wanted. The magic CSS line to flip the card is transform-style: preserve-3d;. I'm also going to add transition: all 0.8s ease; to .card to make the animation transition look more natural.

.card {
  position: relative;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  transform-style: preserve-3d;
  transition: all 0.8s ease;
}

o give the transition a slightly more polished look, let's add perspective: 1000px;.

.container {
  perspective: 1000px;
  position: absolute;
  width: 60%;
  height: 60%;
  background: none;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

Let's spruce up the wording, to make this design as close to real-life as we can, so you can reuse it for your own party!

And I'll add some fonts, while we're here.

<html>
  <head>
    <link rel="stylesheet" href="index.css" />
    <link
      href="https://fonts.googleapis.com/css?family=Tangerine&display=swap"
      rel="stylesheet"
    />
    <link
      href="https://fonts.googleapis.com/css?family=Playfair+Display&display=swap"
      rel="stylesheet"
    />
  </head>
  <body>
    <div class="container">
      <div class="card">
        <div class="front">
          <h1>Your Invitation to Celebrate With Us</h1>
          <p>Please turn the card to reply</p>
        </div>

        <div class="back">
          <h1>RSVP</h1>
          <p>We would be thrilled for you to celebrate with us.</p>
          <button>Yes, I'd love to come</button>
          <button>Unfortunately, I'm busy</button>
        </div>
      </div>
    </div>
  </body>
</html>

Responsive typography

Having good effects is nice, but if the text looks bland, the card just won't cut it.

Normally, there are two most common issues with CSS. Being able to react to changing requirements with minimum changes and maintaining px values everywhere. :D

This is when rem comes to the rescue.

A rem is the font-size value to your root element, i.e <html> element.

By default, it's not written, but it's as if:

html {
  font-size: 16px;
}

That means that when we set font-size: 1rem; it's the same as font-size: 16px;. So if we want to scale things out, we change one value and everything follows suit.

Let's see what that would look like with our card.

h1 {
  font-family: 'Tangerine', cursive;
  font-weight: bold;
  font-size: 1.8rem;
  text-align: center;
}

.front h1 {
  padding: 3rem;
}

.back h1 {
  padding: 2rem;
}

p {
  font-family: 'Playfair Display', serif;
  padding: 1.8rem;
  font-size: 1rem;
  font-weight: normal;
  text-align: center;
}

button {
  padding: 1rem;
  font-size: 0.75rem;
}

A nice touch would be to add some colour to the button when it's hovered over.

button:hover {
  cursor: pointer;
  background-color: lightgray;
}

But hey, when the window is resized, it destroys the look of the card. Doesn't look that great.

To fix it, we can use min- max- prefixes on width and height.

container {
  perspective: 1000px;
  position: absolute;
  width: 60%;
  max-width: 30rem;
  min-width: 25rem;
  height: 60%;
  min-height: 17rem;
  max-height: 20rem;
  background: none;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

And that's it! Hope you enjoyed the article! Feel free to comment and if you want to have a chat, I'm @michael_mynah on Twitter.

Special thanks @perborgen for inspiring this post ;)