Ну, абстракции как раз таки для этого и нужны) чем ниже мы идем в уровень абстракций тем более полную картину мы видим, но нам это не всегда нужно. Иногда достаточно знать что принимает данный уровень абстракции и что возвращает (black-box behavior), и не запариваться деталями имплементации Хоками не добиться того же уровня абстракций что дают хуки и наоборот тоже, вдруг ты запаришься передавать внутрь пропсы и писать return стэйтменты, тогда очевидно тебе поможет хок

black box С хуками это может быть простой компонент

Всем привет! Тестирую компоненты с помощью Enzyme и Jest. Возникла задача: Есть компонент Home, в него вставлен компонент NavTop, и переданы пропсы с методом getFilterItemValue (onFilterItemValue={this.getFilterItemValue}) . Внутри NavTop есть элемент, по клику на который вызывается метод onFilterItemValue из пропсов, который уже в компоненте Home вызывает его метод getFilterItemValue: // Метод компонента Home getFilterItemValue = (itemText, itemId) => { const { filterItemValueAction: handleAction } = this.props; handleAction(itemText, itemId); }; Задача: нужно протестить, чтобы когда мы кликаем на метод getFilterItemValue в дочернем компоненте NavTop и передаём два аргумента (скажем, text, 'id1'), то надо проверить, чтобы метод getFilterItemValue вызывался и вызвался с двумя аргументами, и какими двумя аргументами.

Привет всем! Я вот тут тренируюсь и немного запнулся. Подскажите, как правильно оформлять состояния, на примере ячеек таблицы. Вот пример просто на css https://codepen.io/anon/pen/agqVxB наводишь на ячейку, она меняет цвет. Как это правильно повторить в реакте? Я передаю две функции (mouseOver/mouseOut) от родителя к этим ячейкам, но в голову лезет только один вариант реализации функции, просто event.target изменять по факту, без изменений в state, но это же не очень правильно, как я понимаю. handleOnMouseOver = ev => { ev.target.classList.toggle('cell--hover'); } Загвостка у меня в чём, в рендере родителя я не понимаю, как мне отличить элемент на который навели мышкой от остальных элементов и добавить/снять класс только у него. Через state смог только сделать одновременное изменение цвета у всех))) Извините за такое объяснение, надеюсь поймёте.

@zarabotaet Кстати, все таки пришлось делать хок, компонент не позволяет вернуться раньше чем мне придется лезть в данные, где пока они грузятся у меня нулл

т.е. if(loading) <Loading/> return <MyComponent data={data.items}> or return <Loading loading={loading}> <MyComponent data={data.items}/> </Loading> // Can't access items of null

ребят а можете еще подсказку дать , как в блоке then сделать setState

вот етот вот код не правильно работает

мне от сервера приходит новая инфа, а оно не рендерит значит я так понимаю setState ставит прошлое состояние

>doDone Чот в голос

>doDone Чот в голос

ахахах оборжаться

т.е. if(loading) <Loading/> return <MyComponent data={data.items}> or return <Loading loading={loading}> <MyComponent data={data.items}/> </Loading> // Can't access items of null

получается только так ¯\_(ツ)_/¯

получается только так ¯\_(ツ)_/¯

Мне как новичку очень сложно было понять HOF и его частный случай HOC

Мне как новичку очень сложно было понять HOF и его частный случай HOC

Что такое hof

функ высшего

Что такое hof

|| {} выглядит убого

|| {} выглядит убого

отвергая предлагай

const {data = {}} = useQuery(USER) const {current} = data

const {data} = useQuery(USER) const current = data?.current

Два чая комментирующему выше

А аргументы почему так лучше?

const {data = {}} = useQuery(USER) const {current} = data

а если data null ?

Потому что это выглядит визуально проще Вообще стараюсь оператор или пореже использовать

а если data null ?

поэтому я предпочту optional chaining

поэтому я предпочту optional chaining

а если нельзя в проекте этот стейдж?

ни в каком проекте нельзя использовать стейджи, уже давно

забудь про это слово вообще

целесообразность каждого плагина рассматривается отдельно и подключаются они тоже отдельно

но если у вас в проекте nullable queries, особенно если graphql и техлид лбом упирается в "не хочу" то костылей у вас будет ещё много)

единственное что сейчас optional chaining под вопросом (no pun) — это вызовы методов с этим синтаксисом и это абсолютно излишняя фигня. чтение обычных nullable полей ни у кого разногласий уже давно не вызывает, а концепция graphql так и подавно изначально рассчитывает на него

целесообразность каждого плагина рассматривается отдельно и подключаются они тоже отдельно

те мнение не парится от стейдже брать и транспайлить и забывать об этом?

ну вообще говоря о стейдже париться нужно, просто я поясняю почему именно в этом случае можно использовать не парясь

С какого стейджа можно в прод тянуть по вашему?

Лучше всего stage-3 дожидаться как минимум

ну вообще говоря о стейдже париться нужно, просто я поясняю почему именно в этом случае можно использовать не парясь

ну да соглы что с графкл прям напрашивается он

единственное что сейчас optional chaining под вопросом (no pun) — это вызовы методов с этим синтаксисом и это абсолютно излишняя фигня. чтение обычных nullable полей ни у кого разногласий уже давно не вызывает, а концепция graphql так и подавно изначально рассчитывает на него

меня еще смущает скудность документации и в целом не очень ясная позиция по поводу массивов, понятно, что в жс все объекты, но можно было про массивы отдельно написать, например, у нас прекрасно работают штуки типа const foo = arr?.reduce(...), но это было не очевидно)

нет, нет, нет, именно про них я и говорю. вызов методов после optional chaining по хорошему надо в отдельный пропосал

хотя если рассматривать массив как инстанс класса Array, то вроде норм)

a?.() wtf

Optional chaining в варианте, который категорически нельзя тащить в прод

Это как раз та причина, почему он всё ещё stage 1

идея в том, что чтобы безболезненно делать апдейты схемы приложений и чтобы гибко обрабатывать права доступа к ресурсам, в gql все поля по умолчанию nullable, то есть это подразумевает, что приложения учитывают тот факт, что какие-то данные могут им не придти

это не имеет никакого отношения к вздорной концепции с вызовом методов nullable объектов, речь именно о подходе для чтения полей ответа сервера в котором никаких методов нет и быть не может

более того, флоу например явно запрещает использовать optional методы именно с такой мотивацией, тс насколько я понимаю должен скоро имплементировать тоже именно обычное чтение полей

Сухой вывод: если из optional chaining использовать только optional static property access или optional dynamic property access, то можно тащить. Так?

но ведь в си шарпе и прости господи свифте давно используется такой чейнинг с вызовом методов, и там никто не жалуется

там есть типизация

а тут это может усложнить жизнь на самом деле

у тебя код не падает но работает все равно не верно или падает но не там где ты думаешь

Thedevs.network

I can't joint group. What's wrong?

Idk contact their admins

> can't joint

Не флудите

а тут это может усложнить жизнь на самом деле

флоу уже давно поддерживает этот синтаксис, тс в процессе, в нём ничего сверхъестественного нет

флоу уже давно поддерживает этот синтаксис, тс в процессе, в нём ничего сверхъестественного нет

я имелл виду что он просто опасен без типизации

у тебя код не падает но работает все равно не верно или падает но не там где ты думаешь

Optional chaining в джаваскрипте не error-suppersive

По крайней мере в пропозале

https://github.com/tc39/proposal-optional-chaining#faq

ну где-то ты ожидаешь и помнишь что поставил .? а где-то просто забыл (присвоил в переменную) и ожидаешь что она всегда будет

Ну тогда можно сам джаваскрипт назвать "опасным")

ну это просто будет еще один способ ошибится

зато благодаря этому можно избежать других ошибок, и неочевидного кода вида user && user.address && user.address.location

Well, I don't know Russian. Just can speak in English. Sorry

optional chaining всегда возвращает undefined если переменной нет, это хотя бы будет консистентно

зато благодаря этому можно избежать других ошибок, и неочевидного кода вида user && user.address && user.address.location

интерфесы и все окей

нет таких проблем

contract-based programming же

хотя если бэк вернет херю то конечно тут это не поможет

короче надо это фичу юзать очень осознанно

интерфесы и все окей

как это поможет, если есть некоторая вложенность в объекте?

всё равно проверять придется, если бэк, например, не возвращает пустые обьекты вместо их отсутствия (что вполне логично)

как это поможет, если есть некоторая вложенность в объекте?

ну и с чего бы тебе не знать его структуру заранее

мы и так знаем структуру

ну и с чего бы тебе не знать его структуру заранее

это нормально что в объекте есть не все поля

просто некоторых полей нет

++

это нормально что в объекте есть не все поля

ну это уже другой кей который типизация тоже подскажет