Всегда 1 пишу

А что за модалка внутри модалки ? Или внутри ModalBody ?

Это мои косяки)

Когда пишешь об одном, а в этот момент думаешь о другом)

Мне второй больше нравится, хоть понятно откуда пришло

да ну. Жеско написать thus и retrun

:D

Мне второй больше нравится, хоть понятно откуда пришло

В самой разметке не важно откуда оно пришло

В самой разметке не важно откуда оно пришло

Мне важно

как это развидеть

Мне важно

ты в меньшинстве. Но если тебе так удобней, то делай как удобней

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

первый

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

просто перестань писать классы-компоненты и жить станет существенно проще

просто перестань писать классы-компоненты и жить станет существенно проще

Только функциональные компоненты использовать?

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

для меня очевидный минус - повторять хотя бы 2 раза this.props.

Только функциональные компоненты использовать?

да

для меня очевидный минус - повторять хотя бы 2 раза this.props.

++

Зачем тогда реакт вообще?

Зачем тогда реакт вообще?

ты головой ударился?

стейта нет, методы нормальн оне объявишь

методы не нужны)

стейт тоже)

ладно

шучу

recompose

и больше не пишешь говно-классы не пытаешься решить проблему “откуда-что-пришло” с помощью дублирования “this.props.” и “this.state.”

как лучше объявлять prop-types внизу файла или как static метод?

в зависимости от кодстайла на проекте

как лучше объявлять prop-types внизу файла или как static метод?

не использовать классы ?

не использовать классы ?

чёт ты всё как-то очень категорично. Всё же от задачи зависит

чёт ты всё как-то очень категорично. Всё же от задачи зависит

Тебе просто так кажется) Все остальные мнения удаляются.

А классы лучше использовать в тех местах, где стейт есть.

как лучше объявлять prop-types внизу файла или как static метод?

а какая разница?

не использовать классы ?

а лайфсайкл вызовешь в обычной функции?

а лайфсайкл вызовешь в обычной функции?

А зачем??

а лайфсайкл вызовешь в обычной функции?

через recompose

а лайфсайкл вызовешь в обычной функции?

import { lifecycle } from ‘recompose’ если уж сильно понадобится

Есть группа "Next.Js" и знаете, сколько там человек? 2

)

А классы лучше использовать в тех местах, где стейт есть.

только если сложный стейт но тут уже вопрос “а не надо ли его перенести в ридакс?”

а какая разница?

ну просто хотел узнать как обычно делают

только если сложный стейт но тут уже вопрос “а не надо ли его перенести в ридакс?”

Любой стейт. Ты знаешь, что я повёрнут на flow и выводе типов.

Любой стейт. Ты знаешь, что я повёрнут на flow и выводе типов.

?

только если сложный стейт но тут уже вопрос “а не надо ли его перенести в ридакс?”

т. е. ты не используешь классы вообще?

Так что только классы для стейта.

т. е. ты не используешь классы вообще?

+ классы-компоненты не использую

ну просто хотел узнать как обычно делают

всё реально зависит от кодстайла проекта. имхо, static propTypes выглядят лучше, но это имхо

+ классы-компоненты не использую

а в чем профит?

а в чем профит?

кода меньше читать проще писать проще

кода меньше читать проще писать проще

классы вроде работают быстрее

кода меньше читать проще писать проще

Насчёт последнего не факт.

кода меньше читать проще писать проще

а можно на гитхаб ссылочку? я бы посмотрел как это выглядит

Насчёт последнего не факт.

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

классы вроде работают быстрее

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

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

Нет. Их минимум.

я лучше напишу одну короткую строчку и всё будет работать

Стейта мало в компонентах находится.

я лучше напишу одну короткую строчку и всё будет работать

А потом надо будет что-то изменить и лови ошибки в рантайме.

А потом надо будет что-то изменить и лови ошибки в рантайме.

с чего вдруг?

с чего вдруг?

Потому что хоки и компонент не связаны никак.

Потому что хоки и компонент не связаны никак.

кроме того, что они работают вместе

кроме того, что они работают вместе

Верно. На доверии работает.

foo() -> i32 bar(a: i32) связаны как-то? а если так: bar(foo())

А с классами у тебя проект тупо не соберётся, если что-то не так.

А с классами у тебя проект тупо не соберётся, если что-то не так.

пф да соберется ?

пф да соберется ?

Ну, не собиралось пока.

я могу сделать так, что соберется

класс не большая гарантия, чем всё что угодно в жс

Аргументация уровня боженька)

класс не большая гарантия, чем всё что угодно в жс

Большая. Как минимум с точки зрения flow

Там есть привязка к контексту.

божечки

А с классами у тебя проект тупо не соберётся, если что-то не так.

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

Большая. Как минимум с точки зрения flow

а причем тут флоу?

я говорю об обычном реакте)

Любой стейт. Ты знаешь, что я повёрнут на flow и выводе типов.

блин

есть знакомый, который пишет на флоу и рекомпоз

Не, писать без типизации не собираюсь. Нафиг.

и у него флоу также ругается, если сделал, что-то не так

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

При использовании flow у тебя будет меньше ошибок в случае классов, чем с лайфсайклом из рекомпоза.

и у него флоу также ругается, если сделал, что-то не так

Ну правильно. Если есть ошибки, то проект не должен собираться.

Ну правильно. Если есть ошибки, то проект не должен собираться.

спорно, но я согласен. уточню один момент, классы тут не особое влияние имеют

спорно, но я согласен. уточню один момент, классы тут не особое влияние имеют

Тебе нужен контекст, поэтому функции не канают.

Ну правильно. Если есть ошибки, то проект не должен собираться.

а можешь скинуть код какого-нибудь более-менее сложного компонента?

Тебе нужен контекст, поэтому функции не канают.

зачем мне контекст?

Как бы, если flow научился бы работать вот так с хоками, то я бы не писал этот бойлерплейт)

+ не совсем понятно как класс влияет на то что есть ошибки или нет

Как бы, если flow научился бы работать вот так с хоками, то я бы не писал этот бойлерплейт)

так он умеет

Классы дают тебе возможность бизнеслогику писать в этих классах

так он умеет

Покажи пример.

Покажи пример.

покажи пример, где не работает

из за этого в компонентах написаных на классах за частую куча дерьма

class A { state: { a: 1, } update() { this.setState({b: 1}) } }

Покажи как мне это написать с помощью рекомпоза, чтобы код не собрался.