а в чем разница?)

в реакте или околореактовской инфраструктуре ?

в реакте или околореактовской инфраструктуре ?

ога, скоро на вьюшечку начнем все переписывать)

в реакте или околореактовской инфраструктуре ?

effector, react-effector, symbiot

а в чем разница?)

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

ога, скоро на вьюшечку начнем все переписывать)

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

уже месяцев 6 минимум тут ничего не пишу, а вопросы у людей все те же, redux, пиши в стор, юзай стайт, не юзай стайт, народ, было что-то прорывное из апдейтов в реакте за последние года пол?

reach/router, final-form

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

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

reach/router, final-form

спасибо!

effector, react-effector, symbiot

и тебе спасибо, пойду посмотрю)

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

ради холивара и интереса попробуй поднять большой проект на вью и поддерживать его хотя бы год, с командой 3-4 человека

да что там 3... хотя бы вдвоем :)))

ради холивара и интереса попробуй поднять большой проект на вью и поддерживать его хотя бы год, с командой 3-4 человека

два проекта, 5+ человек, и саппорт идет на них намного проще, чем на реактовских которые были у меня. Но ИМХО простота саппорта проекта зависит в первую очередь не от технологии, а от разработчиков

Да, я понимаю о чем вы говорите, но все же не вижу особого смысла пихать одину пропертю в стор, если она используется только в 1 компоненте. Завтра надо будет подумать еще)

Даня Абрамов пишет, что в стор редакса надо класть только необходимое. Глупо хранить номер странице в редакса если она не синхронизируется с беком. Поэтому в хранит номер страницы в локальном стейте норм.

два проекта, 5+ человек, и саппорт идет на них намного проще, чем на реактовских которые были у меня. Но ИМХО простота саппорта проекта зависит в первую очередь не от технологии, а от разработчиков

я не соглашусь с тобой... попробуй сделать проект на перле.....

и попробуй поддерживать его

вот тебе уже и зависимость простоты от технологии

а на хаскеле слабо?

я не соглашусь с тобой... попробуй сделать проект на перле.....

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

я не могу адекватно оценить то, насколько легко поддерживать перл проекты

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

я ни разу не видел, чтобы один и тот же проект на перле делали более одного человека

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

это можно сравнить со сложностью стыковки космических орбитальных станций между собой

когда два анальных отверстия должны четенько подойти друг к другу

я ни разу не видел, чтобы один и тот же проект на перле делали более одного человека

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

Ребят у меня тоже назрел вопрос про HOC-и, в частности хоки которые работают со стором. У меня есть много различных грубо говоря сервисов-хоков, которые расширяют компоненты нужными данными -userProfile, -currentCompany, -activeService .... и т.д. вынес их в хоки т.к. они используются в многих компонентах разного уровня. Смущает то что каждому хоку нужно обращаться к стору и каждый хок заворачивает компонент в connect и получается если компонент используется несколько таких хоков, то он завернется в connect несколько раз? Есть какое то более изящное решение?

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

адекватно, vue гораздо сложнее сапортить

и сама технология тому виной в первую очередь

адекватно, vue гораздо сложнее сапортить

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

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

vue и react разные слегка и для разнях целей на vue - быстро слобать mvp на react относительно быстро и надежно слобать mvp, который прокатит и в продакшине

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

vue и react разные слегка и для разнях целей на vue - быстро слобать mvp на react относительно быстро и надежно слобать mvp, который прокатит и в продакшине

можно в лс скинуть что во вью не подходит для продакшена?)

ну или тут, если не страшно)

можно в лс скинуть что во вью не подходит для продакшена?)

да зачем в лс тут можно и думаю многие поддержат меня

реакст по сути своей мощнее, по технологиям текущим и перспективным

vue немного удобнее и быстрее на старте, но гораздо медленнее в подддержке на дальней дистанции

реакст по сути своей мощнее, по технологиям текущим и перспективным

коль на то пошло, я все еще не увидел ниодной четкой проблемы, типо "А делать в реакте так, а во вью не эдак"

это не провокация, это интерес

коль на то пошло, я все еще не увидел ниодной четкой проблемы, типо "А делать в реакте так, а во вью не эдак"

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

можно в лс скинуть что во вью не подходит для продакшена?)

Шаблоны. Эта прослойка всегда висит куском текста, которую невозможно никак статически проверять на ошибки. В итоге у тебя в проекте валяется множество разрозненых модулей.

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

перспективность можно как-то оценить? кроме диванной аналитики?

есть реальные цифры?

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

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

перспективность можно как-то оценить? кроме диванной аналитики?

это все равно что сравнивать илона маска и роскосмос

коль на то пошло, я все еще не увидел ниодной четкой проблемы, типо "А делать в реакте так, а во вью не эдак"

Аналога файбера во вью даже не планируется.

Шаблоны. Эта прослойка всегда висит куском текста, которую невозможно никак статически проверять на ошибки. В итоге у тебя в проекте валяется множество разрозненых модулей.

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

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

Аналога файбера во вью даже не планируется.

можно линку? я пропустил что это такое

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

типизация уже есть

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

Даже эти рендер функции адекватно не типизируется существующими инструментами.

часть из этого набора только планируется внедрить в vue к концу 19 года

можно линку? я пропустил что это такое

Эван пару дней назад список фич vue3 выпустил.

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

мне думается, что от mixins vue в итоге будет вынужден отказаться, как это давно сделали в реакте :))

т.е. уже прослеживается некое отставание и попытка догнать

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

типа v-show, v-if, v-case

это просто немного улучшает JSX конструкции

так как не требует встраивания js

но вот их реактивность мне не очень нравится

особенно реактивность в связке с vuex

хз народ, как бы почти все аргументы выглядят как "мне не нравится", "где-то написано что я думаю, что оно отстает", "согласно диванной аналитике он хуже" Как по мне, на вью сложнее заговнокодить. Но в итоге, в любом из этих инструментов вы получите какашку если сами не можете писать норм код, или вас заставляют условия, или получите хороший проект если у вас есть для этого возможности. В пользу вью могу лишь сказать то, что большой проект живет и развивается без большого количества доп пакетов и в целом проще (покрайней мере как это было раньше в реакт месяцев 8 назад), больше рамок, но при команде более 3 человек это наоборот упрощает разработку, нет такого как было раньше в реакте, где ты дополнительно ставишь redux + reselect + еще кучу всего и непонимаешь где хранить данные и как их выбирать, и как с ними работать. Но, я не видел реакт проекты, которые бы саппортили реально прокаченные фронты, а на вью у нас тут парень как раз такой, поэтому, я продолжаю топить за то, что в первую очередь проблемы в разработчиках, а не технологиях

нужна помощь ребята в material-ui есть компонент inputLabel и я хочу его зафиксировать его наверху что бы он недвигался label

хз народ, как бы почти все аргументы выглядят как "мне не нравится", "где-то написано что я думаю, что оно отстает", "согласно диванной аналитике он хуже" Как по мне, на вью сложнее заговнокодить. Но в итоге, в любом из этих инструментов вы получите какашку если сами не можете писать норм код, или вас заставляют условия, или получите хороший проект если у вас есть для этого возможности. В пользу вью могу лишь сказать то, что большой проект живет и развивается без большого количества доп пакетов и в целом проще (покрайней мере как это было раньше в реакт месяцев 8 назад), больше рамок, но при команде более 3 человек это наоборот упрощает разработку, нет такого как было раньше в реакте, где ты дополнительно ставишь redux + reselect + еще кучу всего и непонимаешь где хранить данные и как их выбирать, и как с ними работать. Но, я не видел реакт проекты, которые бы саппортили реально прокаченные фронты, а на вью у нас тут парень как раз такой, поэтому, я продолжаю топить за то, что в первую очередь проблемы в разработчиках, а не технологиях

Сложнее? Эм... Отсутствие полной типизации проекта уже ставит крест. Я не раз забывал в шаблоне менять пропсы,что роняло проект в некоторых местах.

нужна помощь ребята в material-ui есть компонент inputLabel и я хочу его зафиксировать его наверху что бы он недвигался label

пиздец... "я хочу его зафиксировать его наверху что бы он недвигался label" прекращай google переводчик юзать уже

Только не говори - пиши без ошибок и будет тебе счастье, пожалуйста.

ERROR: S client not available

а то ведь мы начнем ответы тоже через гугл транслейтор давать :)))

пиздец... "я хочу его зафиксировать его наверху что бы он недвигался label" прекращай google переводчик юзать уже

про че ты?

нужна помощь ребята в material-ui есть компонент inputLabel и я хочу его зафиксировать его наверху что бы он недвигался label

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

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

Ты понял что он хочет сделать?

Ты понял что он хочет сделать?

ага

ага

победитель битвы экстрасенсов?

он хочет, чтобы label всегда был сверху поля

какие та вы неадекватные

и никогда не сползал в само поле ввода

просто пример привел :)))

когда вопрос не очень грамотно переведен с нативного языка

не сползалговоришь

Там класс можно накинуть, чтобы всегда был сверху

спасибо

Ребят у меня тоже назрел вопрос про HOC-и, в частности хоки которые работают со стором. У меня есть много различных грубо говоря сервисов-хоков, которые расширяют компоненты нужными данными -userProfile, -currentCompany, -activeService .... и т.д. вынес их в хоки т.к. они используются в многих компонентах разного уровня. Смущает то что каждому хоку нужно обращаться к стору и каждый хок заворачивает компонент в connect и получается если компонент используется несколько таких хоков, то он завернется в connect несколько раз? Есть какое то более изящное решение?

FYI: не узбек, не нужно отправлять в гугло-переводчик

Ребят у меня тоже назрел вопрос про HOC-и, в частности хоки которые работают со стором. У меня есть много различных грубо говоря сервисов-хоков, которые расширяют компоненты нужными данными -userProfile, -currentCompany, -activeService .... и т.д. вынес их в хоки т.к. они используются в многих компонентах разного уровня. Смущает то что каждому хоку нужно обращаться к стору и каждый хок заворачивает компонент в connect и получается если компонент используется несколько таких хоков, то он завернется в connect несколько раз? Есть какое то более изящное решение?

Вытаскивай логику в стор.

И останется 1 connect. Ничего более.

так она итак в сторе, хоки это просто транспорт между стором и компонентом.

Если у меня есть елемент, у которого position: absolute и top у меня меняется динамически с помощью подписки на scroll

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

Как лучше сделать его перемещение плавным?

спасибо

<TextField id="standard-number" label="Number" value={this.state.age} onChange={this.handleChange('age')} type="number" className={classes.textField} InputLabelProps={{ shrink: true, }} margin="normal" /> вон видишь там InputLabelProps={{ shrink: true, }} заюзай и проблем не будет, только placeholder-ы расставь

<TextField id="standard-number" label="Number" value={this.state.age} onChange={this.handleChange('age')} type="number" className={classes.textField} InputLabelProps={{ shrink: true, }} margin="normal" /> вон видишь там InputLabelProps={{ shrink: true, }} заюзай и проблем не будет, только placeholder-ы расставь

спасибо

спасибо

но тут несколько способов рещить эту проблему на самом деле

у меня такая херня возникает обычно в хроме, когда autofill срабатывает

пришлось в форме логина делать хак небольшой :)))

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

но в разных UI-китах конечно по разному