По работе, нескольким людям надо добавлять записи в гугл таблицу. Мне будет по кайфу, взять этого бота, докинуть базовую валидацию и пусть через него таблицу и заполняют. Потому что редактировать таблицы с телефона это ужас, а там как раз люди с телефона и заполняют, находясь на улице.
Убейтесь об стену со своим export default, автоимпорты будут работать нигде.
get = async (resource, params) => this.instance.get(resource, { params });
Тут async по приколу написан?
5. Валидировать пропсы, использовать типы
Ну хорошо хоть где-то типы есть, еще бы export default выпилить
Есть множество методологий написания CSS, например БЭМ, OOCSS, SMACSS, Atomic CSS и т. п.
Я вот вообще не понимаю, как БЭМ созданных для того что бы стили не ломались при копи-пасте разметки и отсутствию тулзов, применим к Vue и Angular где есть изоляция стилей и директивы. Опишите, что именно считается блоком, а что элементом? И как сюда присунуть модификаторы и эффективно управлять ими из кода?
Так вьюшки или страницы? Или это два разных типа компонент? Как это вы называете? Давайте придем к единому стандарту.
API/services
Аналогичный вопрос.
Interfaces, enums
Вы действительно считаете, что так удобно? Быть может стоит хранить интерфейсы енумы по месту первичного использования? Например если это используется в пропсах блока, то лучше к блоку. Если возвращается api, то рядом с api.
export function getProduct (id) {
return axios.get(`${API_URL}/products/${id}`)
}
export function postProduct (data) {
return axios.post(`${API_URL}/products`, data)
}
export function patchProduct (data) {
return axios.patch(`${API_URL}/products`, data)
}
Почему это три функции, а не класс с двумя методами (я видел, что именно так в Angularделают)? А почему нет ts-типов?
Это может быть удобным решением для хранения данных, так как чаще всего в больших приложениях есть данные, которые используют на нескольких страницах или в нескольких частях приложения. К таким относятся данные учетной записи пользователя или конфигурация приложения.
Зачем здесь стор? Почему мы не можем сделать глобальный объект-экземпляр класса, который хранит эти данные? Зачем писать куча каши со стором? Мне кажется что использовать сервисы как в Angular и получать их через inject, было бы удобнее (Там правда ручками надо поколдовать с созданием зависимостей), но у меня нет опыта реализации этого на множестве промышленных проектах.
Вообще весь 3-й совет, я так и не понял. Если данные могут использоваться на нескольких страницах то кажется должен подходить provide/inject. В класс-обертка для api-сервиса, может помочь реализовать кэширование? В Angular не используют глобальный стор (ну кроме пары извращенцев) и как-то живут. Почему этот подход нельзя использовать во Vue?
САМОЕ ГЛАВНОЕ!!! Вы забыли совет номер 0: используйте Typescript. Настройте линтер на strict mode, запрет any, а так же js-файлов.
Ну такое себе под постом про vue спрашивать об этом. Но мое мнение, что Angular или Vue. При этом Vue кажется более перспективным.
В Angular уже есть дефолтаная архитектура, которая уменьшает боль при разработке.
Во Vue дефолтаная архитектура менее жёсткая, собственно за хорошей архитектурой я и пришел а эту статью, но её так и не нашёл здесь. Во Vue 3 уже исправлено множество детских болезней Angular(а здесь они закостылены), плюс гораздо реже сталкиваешься с ограничениями фреймворка.
В React разброд и шатание, это же просто библиотека. Я так и ни разу не увидел хорошей архитектуры на реакте. Киллер-фича реакта это jsx/tsx, так как можно гибко переиспользовать UI компоненты. Хуки, это красивый костыль, но все равно костыль. Composition Api во Vue получше будут. Да и jsx во Vue можно прикрутить.
Vue сейчас очень развит, но нужно придумать хорошую архитектуру к нему. React я врагу не пожелаю, это черная дыра пожирающая бюджет любого проекта, много боли и костылей.
Конфигурация должна быть кодом на Typescript, который json. И все становится хорошо. Вместо ts, можно использовать любой другой статически типизируемый язык. Ныть про то, что нужно таскать с собой node-runtime не нужно, пару сотен мегабайт, это не много. Зато написание конфигурации превращается в кайф.
Как стать программистом с нуля? Да никак. С 2020 года стало тяжело. А с 2022 и подавно. Если у вас действительно нет никаких задатков, то лучше попробовать поискать себя в другой профессии. До 2020 года, я всем советовал учиться программированию или идти на курсы по тестированию. И если раньше усердия было достаточно, то сейчас нет. Поезд уже ушёл, быстро и легко войти в профессию не получится. А если хочется долго и тяжело, то иди писать код, а не читай неочемные статьи.
Статья ни про что. Очевидно что человеку без опыта нужно найти хоть какое-то место работы. И ему нужно спамить резюме и отклиться на все подряд.
Было бы гораздо интреснее увидеть анализ рынка. Какие специальности нужны, и какие навыки для этих специальностей. А то пойдут на курсы по питону и не понимают почему не могут найти работу. (Ответ: потому что выпускников питон-курсов как грязи, а вакансий не так много, как например по node.js или фронту.)
Все слишком очевидно. Тут нет ничего nodejs-специфичного, это все общие советы по оптимизации. А вот, сборка приложения в бандл при помощи приложения esbuild здесь нет, а это важно. Вот лучше разберитесь как его лучше настраивать для nest/next/nuxt, что бы оно вырезало не используемый код и напишите об этом статью.
Уж, лучше такой плохой перевод где посыл статьи понятен, полезен и применим, чем очередна статья, про "как я выгорел", "как я переехал" и "какой там вышел новый смартфон".
REST, это что-то про что спрашивают на собеседовании, а на деле каждый клепает свой REST, когда появляется не круд или фильтров настолько много, что они не влазит query-parameters. Поэтому лучше использовать что-то, что более-менее стандартизированно. Ибо под REST каждый понимает, что-то своё. Мало кто говорит про рест читал что-то в духе https://restfulapi.net/ Поэтому RPC/graphql лучше чем неразбериха с REST.
Совсем стыда нет? Это даже не реклама, а позор? Вышла не игра, а какой-то видосик, который даже не раскрывает гейм плей. Чисто эксплуатация народного фольклора. Какое это вообще имеет отношение к тематике хабра?
Как по мне статья выглядит как не обработанный поток сознания. Где-то не расписаны важны вещи, где-то присутствуют не нужные детали. Статья выглядит как маркетинговый бушлит, видимо по этому и минусуют за рекламу.
Хотя тема интересная, например упоминание превьюшек в телеграмме уместно. Или же тезис о том, что вместо семантик веба доменируют агрегаторы. Twitter/Telegram для блогов, Youtube для видео, Wildberries/Ozon вместе сотни интернет магазинов.
Перечитывайте текст и старайте понимать где нужно подробнее, а где нет. (Можно прятать не существенные подробности под спойлеры).
А про что статья?
По работе, нескольким людям надо добавлять записи в гугл таблицу. Мне будет по кайфу, взять этого бота, докинуть базовую валидацию и пусть через него таблицу и заполняют. Потому что редактировать таблицы с телефона это ужас, а там как раз люди с телефона и заполняют, находясь на улице.
Убейтесь об стену со своим export default, автоимпорты будут работать нигде.
Тут async по приколу написан?
Ну хорошо хоть где-то типы есть, еще бы export default выпилить
Я вот вообще не понимаю, как БЭМ созданных для того что бы стили не ломались при копи-пасте разметки и отсутствию тулзов, применим к Vue и Angular где есть изоляция стилей и директивы. Опишите, что именно считается блоком, а что элементом? И как сюда присунуть модификаторы и эффективно управлять ими из кода?
@nkalacheva
P.S. Скудное количество материала, еще хуже чем предыдущая часть. Не пишите такой мусор.
А можно код рабочего приложения? Можно без вашей бизнес логики.
Читал, что там есть некое подобие di, но так и не понял как это заставить работать. Может быть у вас есть пример кода/проект где настроем di?
Так вьюшки или страницы? Или это два разных типа компонент? Как это вы называете? Давайте придем к единому стандарту.
Аналогичный вопрос.
Вы действительно считаете, что так удобно? Быть может стоит хранить интерфейсы енумы по месту первичного использования? Например если это используется в пропсах блока, то лучше к блоку. Если возвращается api, то рядом с api.
Почему это три функции, а не класс с двумя методами (я видел, что именно так в Angularделают)? А почему нет ts-типов?
А почему типы здесь появились?
Зачем здесь стор? Почему мы не можем сделать глобальный объект-экземпляр класса, который хранит эти данные? Зачем писать куча каши со стором? Мне кажется что использовать сервисы как в Angular и получать их через inject, было бы удобнее (Там правда ручками надо поколдовать с созданием зависимостей), но у меня нет опыта реализации этого на множестве промышленных проектах.
Вообще весь 3-й совет, я так и не понял. Если данные могут использоваться на нескольких страницах то кажется должен подходить provide/inject. В класс-обертка для api-сервиса, может помочь реализовать кэширование? В Angular не используют глобальный стор (ну кроме пары извращенцев) и как-то живут. Почему этот подход нельзя использовать во Vue?
САМОЕ ГЛАВНОЕ!!! Вы забыли совет номер 0: используйте Typescript. Настройте линтер на strict mode, запрет any, а так же js-файлов.
@nkalacheva
Ну такое себе под постом про vue спрашивать об этом. Но мое мнение, что Angular или Vue. При этом Vue кажется более перспективным.
В Angular уже есть дефолтаная архитектура, которая уменьшает боль при разработке.
Во Vue дефолтаная архитектура менее жёсткая, собственно за хорошей архитектурой я и пришел а эту статью, но её так и не нашёл здесь. Во Vue 3 уже исправлено множество детских болезней Angular(а здесь они закостылены), плюс гораздо реже сталкиваешься с ограничениями фреймворка.
В React разброд и шатание, это же просто библиотека. Я так и ни разу не увидел хорошей архитектуры на реакте. Киллер-фича реакта это jsx/tsx, так как можно гибко переиспользовать UI компоненты. Хуки, это красивый костыль, но все равно костыль. Composition Api во Vue получше будут. Да и jsx во Vue можно прикрутить.
Vue сейчас очень развит, но нужно придумать хорошую архитектуру к нему. React я врагу не пожелаю, это черная дыра пожирающая бюджет любого проекта, много боли и костылей.
Конфигурация должна быть кодом на Typescript, который json. И все становится хорошо. Вместо ts, можно использовать любой другой статически типизируемый язык. Ныть про то, что нужно таскать с собой node-runtime не нужно, пару сотен мегабайт, это не много. Зато написание конфигурации превращается в кайф.
А что там по вакансиям веб-разработки на Python? На том же NodeJS их в разы больше. Зачем вообще писать Веб на питоне?
Я почему-то ожидал здесь увидеть "Дмитрий Карловский"
<сарказм>Как ускорить PostgreSQL? Заменить его на Postgres Pro. Он же быстрый мощный, а самое главное российский.</сарказм>
Как стать программистом с нуля? Да никак. С 2020 года стало тяжело. А с 2022 и подавно. Если у вас действительно нет никаких задатков, то лучше попробовать поискать себя в другой профессии. До 2020 года, я всем советовал учиться программированию или идти на курсы по тестированию. И если раньше усердия было достаточно, то сейчас нет. Поезд уже ушёл, быстро и легко войти в профессию не получится. А если хочется долго и тяжело, то иди писать код, а не читай неочемные статьи.
Статья ни про что. Очевидно что человеку без опыта нужно найти хоть какое-то место работы. И ему нужно спамить резюме и отклиться на все подряд.
Было бы гораздо интреснее увидеть анализ рынка. Какие специальности нужны, и какие навыки для этих специальностей. А то пойдут на курсы по питону и не понимают почему не могут найти работу. (Ответ: потому что выпускников питон-курсов как грязи, а вакансий не так много, как например по node.js или фронту.)
Все слишком очевидно. Тут нет ничего nodejs-специфичного, это все общие советы по оптимизации. А вот, сборка приложения в бандл при помощи приложения esbuild здесь нет, а это важно. Вот лучше разберитесь как его лучше настраивать для nest/next/nuxt, что бы оно вырезало не используемый код и напишите об этом статью.
Уж, лучше такой плохой перевод где посыл статьи понятен, полезен и применим, чем очередна статья, про "как я выгорел", "как я переехал" и "какой там вышел новый смартфон".
С реактом можно освоить больше бюджета. И менеджеры будут больше зарабатывать.
REST, это что-то про что спрашивают на собеседовании, а на деле каждый клепает свой REST, когда появляется не круд или фильтров настолько много, что они не влазит query-parameters. Поэтому лучше использовать что-то, что более-менее стандартизированно. Ибо под REST каждый понимает, что-то своё. Мало кто говорит про рест читал что-то в духе https://restfulapi.net/ Поэтому RPC/graphql лучше чем неразбериха с REST.
Esbuild?
Совсем стыда нет? Это даже не реклама, а позор? Вышла не игра, а какой-то видосик, который даже не раскрывает гейм плей. Чисто эксплуатация народного фольклора. Какое это вообще имеет отношение к тематике хабра?
Как по мне статья выглядит как не обработанный поток сознания. Где-то не расписаны важны вещи, где-то присутствуют не нужные детали. Статья выглядит как маркетинговый бушлит, видимо по этому и минусуют за рекламу.
Хотя тема интересная, например упоминание превьюшек в телеграмме уместно. Или же тезис о том, что вместо семантик веба доменируют агрегаторы. Twitter/Telegram для блогов, Youtube для видео, Wildberries/Ozon вместе сотни интернет магазинов.
Перечитывайте текст и старайте понимать где нужно подробнее, а где нет. (Можно прятать не существенные подробности под спойлеры).