Работаю как Junior React-разработчик (React 18, Redux, TypeScript) уже 3-й месяц.
Столкнулся с тем, что более-менее нестандартные задачи, требующие более глубокого понимания работы всех механизмов мне очень сложно даются (например четкое понимание асинхронности, работы с промисами и callback-функциями).
Задачи, такие как создание новых страниц в приложении на основе старых, подключение запросов, прикручивание пагинации, копипаст экшенов, редюсеров и.т.д и.т.п решаются относительно просто, т.к есть на что опереться. Нужно создать новую страницу с таблицей данных, фильтрами, поиском и сортировкой - посмотрел уже готовую страницу, взял готовые куски, переделал под себя, все проверил - готово.
Если же задача требует четкого понимания каждого шага работы программы - тут сразу проблема.
Насколько полезно будет, например, отойти на время от готового React, Axios и.т.д., и попробовать, например, реализовать что-то на чистом JS, используя модули, fetch и все нативное? Или это больше бесполезная трата времени?
Думается, что при написании велосипедов и использовании только нативных возможностей языка и браузера, при конструировании приложения лично сталкиваешься с проблемами, эффективным решением которых занимаются готовые библиотеки. И вот тогда суть улавливается.
Работая с готовыми библиотеками куда не плюнешь - везде абстракции над абстракциями. А хочется самую суть уловить и уложить в голове, чтобы получился крепкий фундамент.
Начал писать пет-проект опять же на React, но чувствуется, что и там много пробелов.
Основная цель - получить крепкие фундаментальные знания по JS и веб-разработке в целом, при этом продолжая использовать React, как основной инструмент в настоящем и будущем.
Может вы что-то подскажете и поделитесь своим опытом. Буду благодарен.
Думается, что при написании велосипедов и использовании только нативных возможностей языка и браузера, при конструировании приложения лично сталкиваешься с проблемами, эффективным решением которых занимаются готовые библиотеки. И вот тогда суть улавливается.
Хорошо сказано.
Пишите в качестве пэт-проекта, демо или пруф-оф-консепт. В прод велосипеды тащить не надо.
Есть ещё ненулевой шанс, что ваш велосипед окажется пригодным для серийного производства.
Я зашел в разработку на стеке Vue и его окружения Nuxt, Vuex и т.п.
Начал копать в суть вещей только уже когда понял, что могу что то делать, но уперса в то, что не понимаю как некоторые вещи работают под капотом и это мешает мне делать задачи => недает расти по ЗП.
В общем есть смысл ковырять, если чувствуешь, что стоишь на месте из за того, что не знаешь как реализовать что либо если делаешь шаг влево\вправо.
Если что-то в готовом решении кажется сложным, значит ты не уловил какие именно проблемы успели порешать те, кто это решение писал.
Можно написать свой велосипед, но пока будешь его писать, скорее всего столкнешься с этими проблемами и в попытках решения их собственно напишешь то, что уже сделано.
Писать велосипеды - полезно для себя. Для какихто простых вещей.
В проекте использовать можно, но палка о двух концах - готовое решение в разы проще поддерживать. Возможные баги возможно пофиксят за тебя, тебе просто версию обновить. Если свой проект кому-то передавать то с велосипедами это будет жесть. Разбираться в чужих велосипедах, к которым нет документации - это худшее что может быть.
Поэтому свои велосипеды пиши или в очень простых кейсах или когда уже будешь четко понимать зачем ты решил не юзать готовое.
смысл в том что надо всё делать стандартно
для всего гуглить готовое решение
чтобы тебя можно было в любой момент уволить и без тебя легко всё поддерживать
для капиталиста нет ничего важнее этого
для возможности этого можно пожертвовать качеством
делай свои фреймворки если ты инженер
если у тебя инженерные изобретательские таланты и позывы
а если ты обычный чесальщик-мотальщик кода то изобрерать велосипеды тебе вредно
лучше изучай инструмент, и следи за новыми версиями, то есть вечно страдай
и если повезет - станешь руководителем, и страдать будут другие
Бест практис и патерны быстро меняются. Тот стек технологий и библиотек, который был популярен 3 года назад уже не актуален сегодня, так как все развивается и меняется в быстром темпе, который задается теми, кто понимает, как вещи устроены. Самому менять и выдумывать что-то в продакшене просто приведет к тому, что проект будет зависим от тебя, только ты будешь понимать, что там происходит. Это конечно же не хорошо. Разработка должна быть понятной другим и соответствовать требованиям заказчика прежде всего...
Какие паттерны быстро меняются?)) Паттерны проектирования описали несколько десятилетий назад. Архитектурые шаблоны - тоже большой скорости развития не наблюдается.
