Т
У реакт разработчиков к сожалению очень част проблемы с архитектурой
У тебя есть какая то статистика ?
Size: a a a
2021 January 09
А
У тебя есть какая то статистика ?
Это предвзятое суждение и личное наблюдение)
А
Это предвзятое суждение и личное наблюдение)
Я и сам JS разработчик на реакте, но есть проблема, что большинство курсов и книг по JS, и фреймворкам вообще не затрагивают такую тему как архитектура.
В результате 90 процентов людей прогают, как научились.
В результате 90 процентов людей прогают, как научились.
Т
Я и сам JS разработчик на реакте, но есть проблема, что большинство курсов и книг по JS, и фреймворкам вообще не затрагивают такую тему как архитектура.
В результате 90 процентов людей прогают, как научились.
В результате 90 процентов людей прогают, как научились.
Потому что это все не в этих книгах. Это же все общие темы программирования, не зависящие от фреймворков и языков
А
Потому что это все не в этих книгах. Это же все общие темы программирования, не зависящие от фреймворков и языков
Я согласен и не спорю. Но когда изучаешь мобильную разработку и бэкенд, часто в материалах и курсах даже для начинающих затрагивается тема архитектуры, и гораздо более углубленно чем в обучающих материалах по веб фреймворкам.
D
Я и сам JS разработчик на реакте, но есть проблема, что большинство курсов и книг по JS, и фреймворкам вообще не затрагивают такую тему как архитектура.
В результате 90 процентов людей прогают, как научились.
В результате 90 процентов людей прогают, как научились.
Мне кажется архитектура это такая вещь, которая приходит с опытом. Не бывает так что ты начинаешь прогнать и у тебя сразу все идеально и поддерживаемо )
А
Например обучение той же самой мобильно разработки начинается с разбора архитектурнах MVX паттернов.
А реакт же часто используют не как UI фреймворк
А реакт же часто используют не как UI фреймворк
А
Мне кажется архитектура это такая вещь, которая приходит с опытом. Не бывает так что ты начинаешь прогнать и у тебя сразу все идеально и поддерживаемо )
Безусловно, даже прочитав робета мартина несколько раз не начнешь писать с отличной архитектурой.
Но просто я наблюдаю такую проблемму, что люди даж не пытаются построить хорошую архитектуру.
Все засунем в хуки и редакс, и отлично
Возможно это везде так, но я фронтендер, и наблюдаю здесь такую проблему
Но просто я наблюдаю такую проблемму, что люди даж не пытаются построить хорошую архитектуру.
Все засунем в хуки и редакс, и отлично
Возможно это везде так, но я фронтендер, и наблюдаю здесь такую проблему
RS
Безусловно, даже прочитав робета мартина несколько раз не начнешь писать с отличной архитектурой.
Но просто я наблюдаю такую проблемму, что люди даж не пытаются построить хорошую архитектуру.
Все засунем в хуки и редакс, и отлично
Возможно это везде так, но я фронтендер, и наблюдаю здесь такую проблему
Но просто я наблюдаю такую проблемму, что люди даж не пытаются построить хорошую архитектуру.
Все засунем в хуки и редакс, и отлично
Возможно это везде так, но я фронтендер, и наблюдаю здесь такую проблему
А чем стратегия хуков и редакса (любого стм) плоха?
А
А чем стратегия хуков и редакса (любого стм) плоха?
Она не плоха по сути.
Но то как ее используют, нельзя назвать хорошей архитектурой
Но то как ее используют, нельзя назвать хорошей архитектурой
RS
Она не плоха по сути.
Но то как ее используют, нельзя назвать хорошей архитектурой
Но то как ее используют, нельзя назвать хорошей архитектурой
В основном проблема в том, что никто не думает наперед, а решает текущую задачу способом которым умеет
А
Вот например взять тот же самый Apollo, там есть хуки useQuery, useMutation и тд.
И ты уже в своем компоненте пользуешься этим хуком. Это хорошо? Если это маленькое приложение, то ок.
Если это что то побольше то уже не ок. Потому что в один момент, может быть принято решение перейти на REST, grpc или еще что то модное. И тут появится проблема, что придется бегать по каждому компоненту и менять useMutation на юзМодернТехнолоджиПост.
Ив этом проблема. Потом учто приложение должно быть разделено на слои. И Такая логика должна хранится не в слое UI и не в слое приложения (СтейтМенеджмента) а слое репозитория. И в таком случае любые изменения технологий и сервисов пройдут безболезннно.
И ты уже в своем компоненте пользуешься этим хуком. Это хорошо? Если это маленькое приложение, то ок.
Если это что то побольше то уже не ок. Потому что в один момент, может быть принято решение перейти на REST, grpc или еще что то модное. И тут появится проблема, что придется бегать по каждому компоненту и менять useMutation на юзМодернТехнолоджиПост.
Ив этом проблема. Потом учто приложение должно быть разделено на слои. И Такая логика должна хранится не в слое UI и не в слое приложения (СтейтМенеджмента) а слое репозитория. И в таком случае любые изменения технологий и сервисов пройдут безболезннно.
А
И точно также можно будет поменять Реакт на Вью, потому что та логика которая не отвечает за слой UI будет отделена от слоя представления.
RS
С тем же успехом можно сказать что и реакт должен быть отдельным слоем и легко заменяемым, но на практике такое много кто пишет?
w
И точно также можно будет поменять Реакт на Вью, потому что та логика которая не отвечает за слой UI будет отделена от слоя представления.
получается все запросы к серверу должны уметь работать сами по себе и без UI и быть как полноценная система которую я потом просто покажу не в локал сторейдже или где-то еще а на странице сайта?
я правильно понял?
я правильно понял?
RS
Суть в том что это все дорого, переписать useQuery раз в год потратив пару рабочих дней дешевле изначального построения чистой архитектуры
И
Вот например взять тот же самый Apollo, там есть хуки useQuery, useMutation и тд.
И ты уже в своем компоненте пользуешься этим хуком. Это хорошо? Если это маленькое приложение, то ок.
Если это что то побольше то уже не ок. Потому что в один момент, может быть принято решение перейти на REST, grpc или еще что то модное. И тут появится проблема, что придется бегать по каждому компоненту и менять useMutation на юзМодернТехнолоджиПост.
Ив этом проблема. Потом учто приложение должно быть разделено на слои. И Такая логика должна хранится не в слое UI и не в слое приложения (СтейтМенеджмента) а слое репозитория. И в таком случае любые изменения технологий и сервисов пройдут безболезннно.
И ты уже в своем компоненте пользуешься этим хуком. Это хорошо? Если это маленькое приложение, то ок.
Если это что то побольше то уже не ок. Потому что в один момент, может быть принято решение перейти на REST, grpc или еще что то модное. И тут появится проблема, что придется бегать по каждому компоненту и менять useMutation на юзМодернТехнолоджиПост.
Ив этом проблема. Потом учто приложение должно быть разделено на слои. И Такая логика должна хранится не в слое UI и не в слое приложения (СтейтМенеджмента) а слое репозитория. И в таком случае любые изменения технологий и сервисов пройдут безболезннно.
С другой стороны, ты можешь подойти к разработке большого приложения со стороны проектирования всех слоев, построения луковичной архитектуры, придумать как использовать кучу паттернов, описать доку по выбранной архитектуре и начать писать фичи. На второй фиче приходит заказчик и говорит «а чем ты занимался три месяца? собирай вещи»
Т
С тем же успехом можно сказать что и реакт должен быть отдельным слоем и легко заменяемым, но на практике такое много кто пишет?
С эффектором так сделать проще)
R
С другой стороны, ты можешь подойти к разработке большого приложения со стороны проектирования всех слоев, построения луковичной архитектуры, придумать как использовать кучу паттернов, описать доку по выбранной архитектуре и начать писать фичи. На второй фиче приходит заказчик и говорит «а чем ты занимался три месяца? собирай вещи»
Вот обычно мне менеджер так и говорит :(