Все статьи на webdevkin.ru

В этом году я писал итоги 2 раза. Написал первый раз, перечитал и сжег к чертовой матери, потому что получилось совсем грустно. Второй раз писал уже по-другому. Это не отчет по цифрам, это не планы на будущее, это чувства и эмоции, которые были со мной в 2019-м.

Настала и моя пора поумничать на эту тему

Не буду говорить об алгоритмах, нативном js, ES6-7 и подобных вещах - это и так понятно. Учить общую теорию и практики нужно. Но сегодня речь о другом. Angular, React, Vue - что выбрать?

Angular. Если уже знаете его, то отлично. На ангуляре написаны тысячи приложений и кормить фронтендщиков он будет еще не один год. Но начинать изучать его в 2020-м ни к чему. React и Vue популярнее и проще.

Продолжаем разбираться с vue и строить нашу админку магазина. Сегодня мы будем заниматься динамическими роутами от vue-router, сделаем карточку товара и посмотрим, как сделать несуществующую страницу. Попутно глубже познакомимся с геттерами vuex, заведем еще больше конфигов в приложении и порассуждаем, зачем они нужны.

Погнали.

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

Роутинг в Single Page Application, что может быть проще? В любом javascript-фреймворке роутинг реализовывается десятью строчками кода. Vue.js, конечно же, тоже это позволяет.

Открываем документацию по vue-router, разбираемся. Вроде все просто. Ставим npm-пакет vue-router, прописываем, по какому урлу какие компоненты отрисовывать, и немного меняем html-шаблон. То есть страница приложения выглядит примерно так

Докер везде. Когда-то на него смотрели, как на очередную забаву неугомонных программистов, но докер оказался не таков. Если раньше в любой вакансии писали jquery и zend framework, то сейчас - git и docker. Не удивлюсь, если докер станет таким же стандартом, как и гит в свое время. Или уже стал, это я только из пещеры вылез.

Зачем мне понадобился докер? Ну не знал и не знал, сидел не умничал, сейчас-то что началось?

Разбираться с ним меня сподвигли вы, дорогие читатели. Да ладно? Серьезно. Четверть вопросов по интернет-магазину звучит примерно так: не работает, что делать? Почти всегда причина в том, что нужно настроить окружение. Поставить веб-сервер, завести php и mysql, развернуть базу и прочие рутинные штуки.

Вопрос разворачивания рабочего окружения для веб-проектов волновал меня давно.

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

Сначала выберем проект, в котором будем делать авторизацию. Сначала я хотел сделать отдельный, но потом подумал, а зачем? У нас есть админка интернет-магазина, которая прекрасно подойдет для экспериментов. Админка написана на vue.js, но если вы им не интересуетесь, не беспокойтесь. Мы сделаем так, чтобы авторизацию можно было прикрутить к любому проекту. Не копипастнуть, конечно, но весь код можно будет переиспользовать.

Давайте начнем. Осторожно, это прям лонгрид.

Сегодня мы заканчиваем работать с брендами, нам осталось сделать лишь редактирование. В нашей админке редактирование - это изменение заголовка бренда. Это будет очень короткий урок. Начали.

Сначала определим, как будет выглядеть это редактирование. Можно было сделать через то же окошко, что использовалось при добавлении бренда, но хотелось чего-то новенького. Давайте сделаем так: рядом с названием бренда нарисуем иконку, а при клике на нее заголовок пусть меняется на инпут, который можно редактировать. И две кнопки: ОК и Отмена.

Вот так это будет выглядеть

Сколько раз такое было? Начинаешь делать новую задачу, создаешь ветку от мастера, сидишь, коммитишь себе и вдруг - бац! Вылезает бага. Причем из старого функционала, то, что раньше точно работало.

Начинаешь разбираться, откуда эта бага взялась. Для начала переключаешься на мастер, проверяешь - там работает. Ага, значит, это сам в своей ветке накосячил. Надо искать у себя. Каким образом - есть разные варианты.

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

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

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

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

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

Работать с нашим приложением будут не программисты. Представьте менеджера, которому нужно забить в базу 3 сотни товаров, и это до завтра. Он не будет изучать нашу инструкцию, он сядет и сразу будет набивать по списку. Так сделает любой нормальный человек.

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