You first need to undestand the concept of frontend tests.
You should not test the implementation but the behavior
You test like the end user
For instance, imagine a login screen with email and password inputs and a submit button
The test should input the email and the password, then click in the submit button.
| import React, { Fragment, useState, useEffect } from 'react'; | |
| function RepoListHooks() { | |
| const [repositories, setRepositories] = useState([]); | |
| useEffect(() => { | |
| async function getRepos() { | |
| const response = await fetch('https://api.github.com/users/brunomoreno/repos'); |
tgit new fs/xyz [-b master]
git checkout master # ensure we are on master branch
git pull origin master --rebase # ensure master is up to date (fetch upstream && rebase)
git checkout -b fs/xyz # create the new src branch
git push -u origin @ # should we auto push new src branches to remote?
I. Should we auto push new src branches to remote? Maybe a opt-in flag?
Thanks to React hooks you have now happily turned all your classes into functional components.
Wait, all your components? Not quite. There is one thing that can still only be implemented using classes: Error boundaries.
There is just no functional equivalent for componentDidCatch and deriveStateFromError yet.
In our aging react code base we had been using componentWillRecieveProps for situations where we wanted to recalculate "stuff" when props change. Recent versions of react renamed this method to UNSAFE_componentWillRecieveProps for a variety of reasons. We recently went through an exercise where we tried to kill UNSAFE_componentWillRecieveProps once and for all.
The following is a contrived example of how to refactor such a component.
Here's a button component that uses UNSAFE_componentWillReceiveProps to keep its internal state in sync with the external props.
