хы, мы в своё время, пытаясь отвадить коллег юзать устаревшее апи, подумывали все функции переопределить на process.exit :))

Подскажите пожалуйста, никога не работал с реакт, только с вуе немного. Намного ли сложнее сделать групповой видеочат на реакт чем на вуе? И какие доп модули нужны для реакта

никогда*

хы, мы в своё время, пытаясь отвадить коллег юзать устаревшее апи, подумывали все функции переопределить на process.exit :))

ну ты не сравнивай хуй с пальцем

Подскажите пожалуйста, никога не работал с реакт, только с вуе немного. Намного ли сложнее сделать групповой видеочат на реакт чем на вуе? И какие доп модули нужны для реакта

на такой размытый и вместе с тем специфичный вопрос не ответят попробуй архитектуру перенести "на бумаге"

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

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

реакт не сложнее, чем javascript

я не про js спрашиваю)

гагага

это не шутка, я серьезно

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

реакт это маленькая либа которую ты за час изучишь

если ты мистер гениус ее за час изучил, то не значит, что каждый смертный это может)

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

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

реакт это маленькая либа которую ты за час изучишь

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

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

реакт это маленькая либа которую ты за час изучишь

Ор

Так это к самой либе реакта мало отношения имеет, это уже просто разработка любая :)

если ты мистер гениус ее за час изучил, то не значит, что каждый смертный это может)

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

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

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

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

? я засек)

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

начал смотреть на react-router и уже стали вопросы назревать

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

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

начал смотреть на реакт роутер как на говно

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

начал смотреть на реакт роутер как на говно

а что вместо него использовать?

во вью с роутингом все интуитивно понятно

лучше его используй (я про реактовский роутер) хотя официально он не реактовский)

да я понял)

странный троллинг, так юзай вуе

я же сказал, что надо на реакте сделать

а я тебе говорю делай на вуе

я же сказал, что надо на реакте сделать

а ты сделай на вуе

смысл тратить время на реакт?)

уже сделал на вуе

+- одно и тоже делают

но надо на реакт

ну вот и радуйся

че время тратить

потому что это тестовое задание

но надо на реакт

возьми систему управления состоянием mobx (+ конкретное официальное дополнение mobx-state-tree - это хороший "корсет" для архитектуры и более понятно для вьюшника) реакт прикрутишь по ходу дела

я бы вообще абстрагировался от мышления "реакт-приложение"/"приложение на реакте"

я собирался redux использовать

твоя главная задача - избегать возложения на плечи реакт управления сложными (запутанными) состояниями. Я говорю про локальный стейт компонента* хотя сейчас вот только вышла альфа 16.7 с новыми "ракетами" :) там можно запросто использовать reducer'ы для управления локальным состоянием компонента

ну это мое имхо конечно

я собирался redux использовать

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

понял, спасибо

Кстати как саспенс мешать со стейт менеджерами ?

может есть сссылки на простые проекты на реакте? просто для ознакомнелния

понял, спасибо

я дополнил пред-пред последний ответ, но суть не особо меняется. mobx-тематика более объезжена, чем альфа реакта 16.7

твоя главная задача - избегать возложения на плечи реакт управления сложными (запутанными) состояниями. Я говорю про локальный стейт компонента* хотя сейчас вот только вышла альфа 16.7 с новыми "ракетами" :) там можно запросто использовать reducer'ы для управления локальным состоянием компонента

а я вот не согласен. если и брать редакс, то для управления сложным сотоянием прилаги. дробить на маленькие стэйты (вплоть до сбрасывания в null) - да, но не "упрощать бизнес логику до уровня санков" (с)

может есть сссылки на простые проекты на реакте? просто для ознакомнелния

https://github.com/mobxjs/mobx-react-todomvc https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx https://egghead.io/courses/manage-application-state-with-mobx-state-tree

а я вот не согласен. если и брать редакс, то для управления сложным сотоянием прилаги. дробить на маленькие стэйты (вплоть до сбрасывания в null) - да, но не "упрощать бизнес логику до уровня санков" (с)

я говорил не совсем о том redux (или аналоги) - для управления сложным состояниям - это однозначно я говорил об избегании управления сложным состоянием через stateful-компоненты и setState

а я вот не согласен. если и брать редакс, то для управления сложным сотоянием прилаги. дробить на маленькие стэйты (вплоть до сбрасывания в null) - да, но не "упрощать бизнес логику до уровня санков" (с)

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

https://github.com/mobxjs/mobx-react-todomvc https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx https://egghead.io/courses/manage-application-state-with-mobx-state-tree

спасибо)

https://github.com/mobxjs/mobx-react-todomvc https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx https://egghead.io/courses/manage-application-state-with-mobx-state-tree

Почему так много мобикс...

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

ну и не понятно еще на самом деле, как это дело все завязать вместе

Почему так много мобикс...

я предложил лишь один из путей

я говорил не совсем о том redux (или аналоги) - для управления сложным состояниям - это однозначно я говорил об избегании управления сложным состоянием через stateful-компоненты и setState

> я говорил не совсем о том сорян

> я говорил не совсем о том сорян

ну я сам виноват, никто не обязан за меня додумывать)

Почему так много мобикс...

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

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

бляяяяяяяя.... вот я и зашкварился

Почему так много мобикс...

в mobx выше степень абстракции от ручных операций по сравнению с redux. В mobx-state-tree есть уже структура model-action-component (логика, действия и in-place-component-коннектор в одном флаконе). Для модели предусмотрены динамические ассерты (если нужно), и, на мой взгляд, что самое важное - автор mobx очень хорошо обучает

юзайте эффектор, кстати

@effector_ru

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

redux с библиотекой autodux - это вообще пушка

если ты мистер гениус ее за час изучил, то не значит, что каждый смертный это может)

Реакт это про javascript => знаешь жс проще выкатиться в реакт

redux с библиотекой autodux - это вообще пушка

говно еще то

попробуй завести удобно flow с этой ебатой

ну в плане сорян, не говно

начал смотреть на реакт роутер как на говно

Ахахаха?

если ты хочешь юзать флоу еще - то говно

говно еще то

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

даже не так

говно еще то

:) не знаю, я под Typescript написал аналог в форме небольшого модуля, у меня там поместился reducer, actionCreators, actionPredicates (для rxjs полезно) и scoped-actions поддерживаются

с TS очень просто

у него, насколько я понимаю, в сравнении с flow, низкая степерь инстроспекции кода (это чуть ли не идиологическое различие), однако для поддержки нормального type-inference я все равно должен писать аннотации типов

:) не знаю, я под Typescript написал аналог в форме небольшого модуля, у меня там поместился reducer, actionCreators, actionPredicates (для rxjs полезно) и scoped-actions поддерживаются

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

может быть он и делает вид - но флоу его явно ложит на лопатки.

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

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

тс - это ебота которая тебе мешает, а не помогает

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

тут я не знаю, что сказать, типизирую на TS на уровне рефлексов по большей части. Я большой сторонник аннотаций типов в принципе - так в чем проблема их писать к коду сразу, причем мусора это не особо добавляет

тут я не знаю, что сказать, типизирую на TS на уровне рефлексов по большей части. Я большой сторонник аннотаций типов в принципе - так в чем проблема их писать к коду сразу, причем мусора это не особо добавляет

проблема в выводе этих типов

Аннотации позволяют мне проще выделять абстракции (грубо говоря представлять систему с точки зрения преобразования данных до написания любой имплементации) тут я не знаю, как у других*

то, насколько тс и флоу выводят типы из сложных конструкций

ну ок ок, я же не говорю что тс - это шлак

тс вместо жс это в любом случае лучше

ну ок ок, я же не говорю что тс - это шлак

Ты сейчас демонов вызвал

проблема в выводе этих типов

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

Ты сейчас демонов вызвал

но опять же, это малость несправедливо (мы типы далекооооо не везде пишем)

наверное даже так: флоу - помогает, тс - забыл слово, когда каждый день ты в 6 просыпаешься, занимаешься зарядкой, ешь здоровую пищу - вот это все про тс

Ты сейчас демонов вызвал

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

и?

мне просто тяжело сравнивать A и B, потому что вторым я особо не пользовался. Никаких "и", просто мне интересно было выслушать мнение