Robur

возможно, как-то так

const [data, setData] = useState(null)
async function doStuff() {
  const data = await fetch(...)
  setData(data)
}
....
 <Button onClick={doStuff} />
...

По его специальности 100% не дарить. то что ему надо он уже нашел и прочитал, а ненужное - ненужно.

Подарите вот такую
https://www.litres.ru/robert-satton/ne-rabotayte-s...

то-то слышал про GET, POST, но не знаю как начать и с чего.

Вот с этого и начните, почитайте про HTTP

Чтобы что-то протестировать, надо решить что вы будете тестировать.
Чтобы решить что вы будете тестировать, надо найти что может внезапно поломаться.

Что вы хотите протестировать в этом компоненте такого, что
1. относится к логике этого компонента
2. может незаметно сломаться
3. настолько важно чтобы окупить затраты по написанию-сопровождению теста?

присваивание переменной? это ломаться не должно.
Работу .map (тот пример что вы описали)? это внешняя логика, да и вообще - встроенный функционал.
То что в Recipe вы передаете recipe? это не может сломаться, пока вы сознательно не удалите. В этот момент тест тоже станет не валидным, и он вам ничем не поможет, его надо будет менять.

В общем - не надо его тестировать. Разве что для тренировки, попробовать как оно.

нет такого понятия "рероут".
если компонент рендерится полностью заново - значит в какой-то момент какой-то компонент размонтируется и другой компонент монтируется.
Возможно это делает react-router, а возможно и нет.
Покажите код роута для начала.

Уберите тег react-native.
передать name и time можно через пропсы, используйте render вместо component, тогда сможете передать туда все что захотите:
https://reacttraining.com/react-router/web/api/Rou...

То что вы хотите сделать, правильно делать не так - нужно передавать данные через props,
дальше в useEffect брать эти пропсы и обновлять chartInstance.

Вы нам из 2040 пишете? Такое ощущение что в вашем мире JS код в браузере никто не запускает уже лет 15.

SSR используется в 1% случаев, и то - практически всегда этот же код потом попадет в браузеры и будет там работать, поэтому ему нужен бабель, вебпак и все прочее.

1. Браузер получает JS и выполняет его. Заэтим и нужно все перечисленное.
2. в 2040 это наверное уже не важно, а в нашем 2020 все еще существует куча методов деплоить и разворачивать браузерные приложения.
3. Я не знаю где это у вас все считается на сервере, в нашем 2020 99% кода веб приложений все еще запускается в браузере. 1% - это сборка-транспиляция-дев-серверы.
4. не можем, SSR не для этого, он для того чтобы отдавать клиенту изначально отрендеренный HTML и потом туда грузить приложение. Есть проекты которые рендерят веб-аппы в статические HTML, которые потом отдаются браузеру, но в нашем 2020 это пока еще экзотика.
5. Если довлеет. Но он нет. Хотя идея супер тонких видео клиентов витает в воздухе еще с тех времен когда люди, помнящие теплые ламповые майнфреймы закупились первыми ПК и стали предаваться ностальгии. Такие проекты тоже есть, но они в нашем 2020 еще большая экзотика чем SSR без активного клиента. Хотя я в подобном участвовал лично.
Выразятся ли они в чем-то массовом или нет - время покажет. Мое мнение - нет, заметно проще и дешевле и эффективнее по многим параметрам нарисовать миллион веб страничек на миллионах клиентах, чем на одном большом сервере и отдать всем в виде видео.

Там ведь итак всё строго типизированно... есть ли в этом смысл?

найдите ошибку логики и ошибку типов:

//returnы number increased by one
function addOne(a: number) {
 return a-1
}

во время выполнения App у вас еще нет информации о том, будут ли кнопки срендерены или нет. Вы просто возвращаете дескриптор виртуального дерева.
"рендерить" куда-то в переменную так себе затея.
Возможные решения
- выносить логику из врапперов куда-то выше (где вам надо использовать эту информацию). Например , где Wrapper будет просто содержать инфу об условии а фильтрацию непосредственно делать будет WrappersList, поэтому там же можно сделать что-то еще. Либо, как вариант вынести логику из компонент чтобы ее можно было использовать независимо в Wrapper и WrapperList
- соорудить что-нибудь чтобы передать состояние о том сработал враппер или нет в родительский компонент (колбеки например) и соответственно менять рендеринг в родительском компоненте. Тут главное сделать это аккуратно и без граблей