Всем привет можете помочь, сделал поиск по таблице в классовом компоненте приходят данные из redux загоняю в state.dataerrors затем эти данные фильтрую и отдаю отфильтрованные данные загоняю в state.resultAll через componentDidUpdate. И затем отфильтрованные передаю простому компоненту. Проблема в том что при первом рендере таблица не показывает но при вводе что то в поиске (input) рендерит уже данные, при удаление введенных данных повторно рендерит уже полные данные Вопрос: Как сделать чтобы рендерил все данные но при этом при вводи в поиске или удаление введенных данных возвращался в старое состояние Заранее спасибо

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

в componenDidUpdate противопоказано использовать this.setState 🌚

в componenDidUpdate противопоказано использовать this.setState 🌚

Всем привет! Я иногда делаю свои pet проекты, в т.ч. с использованием ReactJS. Вот смотрю в сторону использования в связке TypeScript. Подскажите плиз как правильно сейчас "носить" React+TS, с точки зрения реализации компонентов? Функции или классы? Как я понимаю, с появлением хуков, рекомендуется использовать функции. Но концепция TS как ООП, ближе к классам. Поделитесь пожалуйста мнением?

Всем привет! Я иногда делаю свои pet проекты, в т.ч. с использованием ReactJS. Вот смотрю в сторону использования в связке TypeScript. Подскажите плиз как правильно сейчас "носить" React+TS, с точки зрения реализации компонентов? Функции или классы? Как я понимаю, с появлением хуков, рекомендуется использовать функции. Но концепция TS как ООП, ближе к классам. Поделитесь пожалуйста мнением?

я предпочитаю писать в стиле, который порождает меньше кода в количестве, но при этом не теряет в читаемости. для меня это функции+хуки, иногда ХОКи, классы и рендер-пропс

Хоки ещё могу прикинуть. А рендер пропсы в каком случае вместо хуком могут быть лучше?

render-prop позволяет рендерить списки и меню красиво.

У меня в таких случаях в голове сидит то, что лучше уж компоненты кидать в таком случае, чем рендер-пропсы. Но это мои забавы.

я не фанат рендер-пропов, но прокидывать компонент хуже. Как минимум это не позволяет установить компоненту пропсы, как максимум, код разбивается на куски, которые приходится читать в разных местах

Как минимум это не позволяет установить компоненту пропсы Вот тут не понял.

Нужно вникнуть, но как по мне увидел два кейса для кастомхукс. Это карточки?

<Example component={Another} /> как установить свои пропсы компоненту Another? <Example render={() => <Another prop={1} />} />

что за кейсы?

Я стараюсь придерживаться апи подобного вида если это уж очень сильно нужно: <Example component={Another} componentProps={props} /> Мне не нравится прокидывать функцию, так как она очень легко превращается в говно, которое зависит от почти от всего замыкания. А прокидывание компонента хотя бы немного позволяют заставлять человека думать.

роуты не лучше перенести в отдельный файл роутов? А если нужно будет пушить в историю - по идее везде будут разбросаны уникальные строки

Виз аккаунт только логику содержит?

зачем это нужно, если уже хуки пишешь? вместо вызова props.render* можно просто возвращать exists, empty

очень давно размышляю на тему роутов и выносить в отдельный файл тоже проблема ибо придется создавать функции вроде ({ cardId }) => /open/${cardId} а значит придется дублировать и в роутах в идеале хочется из списка роутов получить список таких функций. const routing = createRouting(routes) routing.openCard(5) // /open/5

чтобы не городить тернарники и булевы операторы в jsx

Хм куда fetching делося

Хм куда fetching делося

баги, друг мой.

посмотри es6-template-string в нпм, иными словами ты вызываешь метод template и передаешь определенную структуру, а в роутах просто у тебя строка, но в виде шаблонной строки и в остальном работает как шаблонная строка, например () => template(routes.user, variable, {key: ‘id’}) -> будет роут со значением из variable по ключу id сама строка ‘/@${id}’

Ааа. А то думал не проснулся. Мы ж за рендер проп заговорили, вот я и пытался всмотреться зачем тут именно этот паттерн нужен.

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

именно в Authenticated он не нужен

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

Так его нету в визаккаунт.

А тут чисто что б хендлер пробросить?

<Access can="admin.card.delete"> <Button>Delete</Button> </Access> по мне выглядит лучше, чем: const canDelete = withAccess("admin.card.delete") return ( //... { canDelete ? ( <Button>Delete</Button> ) : ( <span>Another</span> ) } //... ) тупо потому, что таких операторов может быть много и при чтении jsx приходится прыгать к определению переменных вроде canDelete

@dreyks ты об этом?

да

там опциональные пропсы же

1. да, чтобы close можно было выполнить без хуков 2. функция рендерится только когда меню отображается

А почему заюзать хук тут было бы хуже?

ну ты ведь в контрпримере юзаешь две ветки, а в своем варианте только одну

Я стараюсь придерживаться апи подобного вида если это уж очень сильно нужно: <Example component={Another} componentProps={props} /> Мне не нравится прокидывать функцию, так как она очень легко превращается в говно, которое зависит от почти от всего замыкания. А прокидывание компонента хотя бы немного позволяют заставлять человека думать.

это да. радует, что заметил))) В этом случае, нужен будет второй <Access который будет иметь отрицание. Что в общем-то не сильно лучше тернарника

А когда ты прокидываешь пропсы в componentProps они не зависят от замыкания?

И поэтому тут я ещё не нашел хорошего решения. Тернарники мне не нравятся, потому что выглядят страшно в jsx. А <Access не имеет хороших else мне предлагали <Access> <Then></Then> <Else></Else> </Access> но это совсем дно, ИМХО

это уже какойто ReactHandlebars :)

1. если у меня 4-5 меню на компонент 2. а если меню вложенные?

В таком случае я бы наверное заюзал контекст и не запаривался настолько с композицией, все равно ею все кейсы не покроешь.

В таком случае я бы наверное заюзал контекст и не запаривался настолько с композицией, все равно ею все кейсы не покроешь.

покроешь, только потом сам же запутаешься в миллионе компонентов :) в любом деле главное не упарываться

В таком случае я бы наверное заюзал контекст и не запаривался настолько с композицией, все равно ею все кейсы не покроешь.