а, бля

Пацы, какая сейчас либа парсинга человеческих строк самая центровая?

почему &:nth-of-type(2n) генерирует мне одинаковые класснеймы в styled-components?

А как вы эти ваши симбиоты с сагами, например, связываете без явного экшен-тайпа?

А как вы эти ваши симбиоты с сагами, например, связываете без явного экшен-тайпа?

You can use action as action type in classic reducer

А как вы эти ваши симбиоты с сагами, например, связываете без явного экшен-тайпа?

не юзаем саги

Коллеги, товарищ готовит доклад по styled-components, расскажите, пожалуйста, как либа дружит со статической типизацией (flow, TS): какие боли, какие радости. Особенности, ограничения, возможные решения?

всегда было непонятно почему народ пишет экшны подобно ADD_TASK UPDATE_TASK REMOVE_TASK, ведь если в проекте кроме задач будут еще n типов объектов то придется писать по 3 экшена на каждый тип - чем плохо написать только 3 типа событий - ADD, UPDATE, REMOVE а тип сущности или имя таблицы просто передавать параметром, например ({type: "ADD", table: "tasks", data: {...}}), и заодно вместо всяких SET_EDITED_TASK написать {type: "UPDATE", table: "tasks", data: {edited: true}} ?

Пацы, какая сейчас либа парсинга человеческих строк самая центровая?

че?

Коллеги, товарищ готовит доклад по styled-components, расскажите, пожалуйста, как либа дружит со статической типизацией (flow, TS): какие боли, какие радости. Особенности, ограничения, возможные решения?

кек. херовый доклад будет видимо

всегда было непонятно почему народ пишет экшны подобно ADD_TASK UPDATE_TASK REMOVE_TASK, ведь если в проекте кроме задач будут еще n типов объектов то придется писать по 3 экшена на каждый тип - чем плохо написать только 3 типа событий - ADD, UPDATE, REMOVE а тип сущности или имя таблицы просто передавать параметром, например ({type: "ADD", table: "tasks", data: {...}}), и заодно вместо всяких SET_EDITED_TASK написать {type: "UPDATE", table: "tasks", data: {edited: true}} ?

такие конвенции. что в редюсере ты делаешь что-то вроде switch(action.type) по двум параметрам сделать будет сложнее да и конвенции ломаются

всегда было непонятно почему народ пишет экшны подобно ADD_TASK UPDATE_TASK REMOVE_TASK, ведь если в проекте кроме задач будут еще n типов объектов то придется писать по 3 экшена на каждый тип - чем плохо написать только 3 типа событий - ADD, UPDATE, REMOVE а тип сущности или имя таблицы просто передавать параметром, например ({type: "ADD", table: "tasks", data: {...}}), и заодно вместо всяких SET_EDITED_TASK написать {type: "UPDATE", table: "tasks", data: {edited: true}} ?

Насчёт "и заодно вместо всяких SET_EDITED_TASK написать {type: "UPDATE", table: "tasks", data: {edited: true}} ?" - для удобного доступа (вместо перебора и проверки, поиска для замены), и избегания не родных полей в модели одного таска

вообще я аж всхрюкнул с table и data

слова которые имеют максимально размытый смысл в этом контексте

Коллеги, товарищ готовит доклад по styled-components, расскажите, пожалуйста, как либа дружит со статической типизацией (flow, TS): какие боли, какие радости. Особенности, ограничения, возможные решения?

А какие конкретно вопросы? вроде откровенных ишью и неработающих кейсов нет, все работает, в ts многовато писать приходится. Про flow кто нибудь лучше другой расскажет

“едит” ?

https://github.com/verbart/todo-react/blob/d613f8f4dcce18abd17e770a2a0c479659564f02/src/components/Task.js#L48

копайте сюда

я вижу, что экшн триггерится только тут

“едит” ?

edit - кнопка редактирования, она должна переключить состояние isEdit

следственно срабатывает событие onChange у Field

такие конвенции. что в редюсере ты делаешь что-то вроде switch(action.type) по двум параметрам сделать будет сложнее да и конвенции ломаются

но если код обновления объекта в редюсерах одинаков для разных типов объектов то для уменьшения дублирования придется матчить по строке "UPDATE_(.*)" и мне это кажется большим костылем чем сделать тип события как "UPDATE" и передавать тип объекта параметром

вообще я аж всхрюкнул с table и data

на бекенде тип сущности обычно называют таблицой поэтому такие ассоциации

копайте сюда

это не та ветка. я дал ссылку на - https://github.com/verbart/todo-react/tree/semantic-ui

на бекенде тип сущности обычно называют таблицой поэтому такие ассоциации

на фронте нет таблиц

но если код обновления объекта в редюсерах одинаков для разных типов объектов то для уменьшения дублирования придется матчить по строке "UPDATE_(.*)" и мне это кажется большим костылем чем сделать тип события как "UPDATE" и передавать тип объекта параметром

тогда лучше сделать аналог redux-orm или redux-symbiote и упростить себе жизнь в существующей экосистеме, а не создавать свою, с неработающим ничем

edit - кнопка редактирования, она должна переключить состояние isEdit

кек. “эдит” так-то, edit и надо писать)

это не та ветка. я дал ссылку на - https://github.com/verbart/todo-react/tree/semantic-ui

полагаю, у вас нажатие на кнопку сабмиттит форму

Насчёт "и заодно вместо всяких SET_EDITED_TASK написать {type: "UPDATE", table: "tasks", data: {edited: true}} ?" - для удобного доступа (вместо перебора и проверки, поиска для замены), и избегания не родных полей в модели одного таска

и у нас получится сотни если не тысячи всяких сочетаний SET_{field}_{entity} если на проекте десяток сущностей и по два десятка полей в каждой сущности и я вижу это как раздувание болерплейта и дублирования на ровном месте. А потом все жалуются что с редаксом получается куча болерплейта.

полагаю, у вас нажатие на кнопку сабмиттит форму

Возможно, но почему, мы же кликаем на кнопку редактировать, а не сохранить?

все кнопки внутри формы по-умолчанию её сабмиттят

какая разница, что вы там на неё навесили

вы поток событий не остановили

клик пошел дальше и засабмиттил форму

все кнопки внутри формы по-умолчанию её сабмиттят

я в курсе, но ведь они не в форме, потому я и дал кнопке сохранения атрибут form

хороший вопрос, не могу ответить с ходу, почему идет подобное поведение

и у нас получится сотни если не тысячи всяких сочетаний SET_{field}_{entity} если на проекте десяток сущностей и по два десятка полей в каждой сущности и я вижу это как раздувание болерплейта и дублирования на ровном месте. А потом все жалуются что с редаксом получается куча болерплейта.

поэтому надо юзать симбиоты)

надо сервисы делать и не мучать себя

Подскажите пожалуйста, в чём может быть проблема? Использую семантик юи и при закрытии модалки получаю вот это >

Вот код

Раньше всё работало без проблем, но потом на каком-то этапе сломалось

Модалка открывается, но закрыть не могу

Буду рад любым подсказкам

почему ты в продакшен версии разрабатываешь?

Проект в стадии доработки, если возможно - хотелось бы увидеть ответ по теме вопроса)

mapActions лучше писать просто объектом const mapActions = { hideModal }

connect первого аргумента не хватает вроде

Все остальные модалки с такой реализацией работают

Проект в стадии доработки, если возможно - хотелось бы увидеть ответ по теме вопроса)

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

Проект к сожалению поднимал не я, нужно фиксить то, что не работает...

А как ты пофиксишь не перекомпилив его?

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

Не хватало первого аргумента в коннект)

@v_today

Спасибо!)

Всем привет! Помогите пожалуйста. Есть textfield для номеров . state number: ' '; Еще есть select с названиями стран. State массив стран вместе с id(0-4) и value(код каждой страны). Пишу если выбран такая-то страна с Id == n, то this.setState({number: "код страны"}). Выводит ошибку

ERROR: S client not available

это не ошибка а warning и в его описании все написано, у тебя value инпута меняется с undefined на какое то значение

Всем привет! Помогите пожалуйста. Есть textfield для номеров . state number: ' '; Еще есть select с названиями стран. State массив стран вместе с id(0-4) и value(код каждой страны). Пишу если выбран такая-то страна с Id == n, то this.setState({number: "код страны"}). Выводит ошибку

неужели так сложно загуглить ошибку и почитать о том, что есть https://reactjs.org/docs/uncontrolled-components.html и https://reactjs.org/docs/forms.html

Я пытался сам решить перед тем как написать сюда

Я пытался сам решить перед тем как написать сюда

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

Но у него есть стейт. number: ' '.

Без select он работает, можно написать и его онСабмит обработает

В инпуте value={this.state.number} работает. А this.setState({number: "123"}) - нет(

https://github.com/reactjs/rfcs/blob/gaearon-patch-2/text/0000-lazy.md

https://github.com/philosaf/observed-bits

`this.setState((prevState, props) => { return {counter: prevState.counter + props.step}; });` Задчем делать prevState, если prevState доступен по this.state?

https://github.com/reactjs/rfcs/blob/gaearon-patch-2/text/0000-lazy.md

Ха-ха, придётся использовать export default

Ха-ха, придётся использовать export default

Эм, нет?

Там же есть вариант для именованных импортов

Как я понял, наоборот, его специально не будут делать

`this.setState((prevState, props) => { return {counter: prevState.counter + props.step}; });` Задчем делать prevState, если prevState доступен по this.state?

здесь без разницы, думаю но вообще эти штуки удобно использовать, если выносишь в отдельные функции, за пределами классов, типа: const doSomething = (prevState, props) => { return {counter: prevState.counter + props.step} } ... this.setState(doSomething)

ребят, такой вопрос! есть контейнер и компонент в контейнере стейт есть, рендерится компонент и туда прокидывается в пропсы данные из стейт. Проблема в том, что пропсы не успевают приходить быстро и ошибка в переборке мапом Как оставить компонент глупым и тем самым правильно рендерить данные с контейнера?

ребят, такой вопрос! есть контейнер и компонент в контейнере стейт есть, рендерится компонент и туда прокидывается в пропсы данные из стейт. Проблема в том, что пропсы не успевают приходить быстро и ошибка в переборке мапом Как оставить компонент глупым и тем самым правильно рендерить данные с контейнера?

проверяй на наличие данных

проверяй на наличие данных

в компоненте?

да

каким образом? он ведь тогда перестанет быть глупым )

каким образом? он ведь тогда перестанет быть глупым )

ну компонент же принимает пропсы. Проверяй их существование. Если их нет, то рисуй спиннер или что-нибудь другое)

ну компонент же принимает пропсы. Проверяй их существование. Если их нет, то рисуй спиннер или что-нибудь другое)

как их проверить то?)

{data && <Comp />}

{data && <Comp />}

тернарка в рендере, это понял, получается рендерится будет спинер или компонент, но не пойму досих пор как отработает проверка пропсов

тернарка в рендере, это понял, получается рендерится будет спинер или компонент, но не пойму досих пор как отработает проверка пропсов

в смысле как?)

в смысле как?)

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

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

{!data ? (<Spinner />) : (<Comp />)}

{!data ? (<Spinner />) : (<Comp />)}

то есть таким образом компонент отрендерится только тогда когда к нему пропсы дойдут?

то есть таким образом компонент отрендерится только тогда когда к нему пропсы дойдут?

Да. Тут даже не в реакте дело. Обычный js)