WPF Binding: Что означает ?
Этой первой статьей я бы хотел начать цикл переводов постов с замечательного блога, в котором Beatriz Costa детально объясняет определенные аспекты Binding’а в WPF. В первом посте затрагивается тема использования Binding’а без указания каких-либо дополнительных свойств.
В основном, Binding’и, которые вы видите в различных примерах, имеют определенные значения свойств Source и Path. Свойство Source определяет объект, на который направляется Binding, а свойство Path определяет свойство у объекта, значение которого вам нужно. Я видела некоторых людей, которых cбивала с толку их первая встреча с пустым Binding’ом — «
Первый подход, это когда источником выступает строка и вы просто хотите указать на всю строку целиком (а, к примеру, не на ее свойство Length).
Заметьте, что у Binding’а внутри DataTemplat’а не определено свойство Source. Это из-за того, что DataContext автоматически устанавливается как Source.
Здесь вы можете найти проект для Visual Studio с кодом, который был использован в статье.
От переводчика:
Автор оригинальной статьи — женщина, поэтому текст перевода написан от женского лица.
Так же хотелось бы узнать, насколько интересна тема Binding’а хабролюдям, и стоит ли продолжать эту серию переводов.
Идея перевода навеяна постом WPF Series: Intro aka Введение.
“Best practices” авторизации для Vue
Feb 27, 2018 · 4 min read
Эта статья является переводом. Оригинал статьи Authentication Best Practices for Vue.
Введение
Всякий раз, когда вы начинаете серьезный проект, у вас возникают следующие вопросы:
Данная статья ответит на эти вопросы, и мы попытается показать, как реализовать всё наилучшим образом.
Вы должны помнить, что все проекты имеют разное поведение при авторизации: можно не пускать пользователей в приложение до авторизации (Gmail) или показывать ограниченный интерфейс (Amazon). Вы можете использовать то, что я опишу здесь, либо реализовать собственный вариант.
Перед началом
Я создал репозиторий на случай если вы хотите запустить код из этой статьи.
Для управлен и я состоянием приложения я использую Vuex, который подходит и для управления авторизацией. Но не беспокойтесь, в статье будут примеры и без использования Vuex. Для ajax запросов будет использоваться Axios.
Вы должны понимать, что эта статья не покажет, как сделать авторизацию на бэкенде. Мы будем работать только с фронтендом.
Авторизация
Начнем с простой формы авторизации
Когда пользователь заполнил все поля и нажал на кнопку “Войти”, я выполняю следующий метод:
Первый важный кусок этого кода
Вы можете рассматривать действия Vuex как Promise и реагировать на успешную авторизацию из компонента. Синхронность данного действия позволит перенаправить пользователя на главную сразу после авторизации и получения токена.
Модуль авторизации Vuex
Теперь рассмотрим модуль авторизации. Для начала инициализируем наше состояние (State). Нам потребуется два свойства: token (используем localStorage, если он имеется) и status, который говорит о статусе вызова API (loading, success или error).
Почему мы используем localStorage, а не cookie? Оба решения хороши, имеют преимущества и недостатки Эта статья и эта страница отвечают на данный вопрос.
Геттер isAuthenticated может показаться излишним, однако в перспективе это лучшее решение для подтверждения пользователя. Имея этот геттер, вы отделяете данные от логики приложения.
Теперь действия (Actions):
Достаточно простой вызов API из модуля. Важными деталями являются:
UPD от переводчика: также ваш URL при регистрации и логине не будет указывать ваши данные, поэтому перехватить их с помощью URL будет невозможно.
Выход
Давайте реализуем логику выхода в modules/auth.js
Когда мы кликаем по кнопке “Выход” в одном из компонентов:
Постарайтесь оставлять простыми действия Login/Logout. Если вы будете делать Login/Logout в одном действии, может возникнуть очень много головной боли с их поддержкой.
Используем токен
Теперь, когда нам удалось получить и записать токен, давайте используем его. В следующем примере используется Axios и заголовки по умолчанию.
После авторизации все заголовки наших запросов подписаны нашим токеном, и вызовы API стали аутентифицированы. Когда мы выходим, мы удаляем наш токен из заголовков.
Автоматическая аутентификация
Если мы перезагрузим страницу с нашим приложением, у нас слетят пользовательские заголовки в Axios. Давайте исправим это!
Теперь после перезагрузки страницы все вызовы API по прежнему подписаны токеном, который мы получили после авторизации.
Сторожевые хуки
Теперь вы захотите ограничить доступ к маршрутам в зависимости от статуса пользователя. В нашем случае мы хотим, чтобы только авторизованные пользователи могли попасть на /account. А пользователи, не прошедшие авторизацию, имели доступ только к /login и /.
Здесь я буду использовать сторожевые хуки, которые позволят нам ограничивать доступ к маршрутам.
Замечание 1: Если вы не хотите использовать Vuex, вы можете проверять наличие токена в localStorage напрямую, без использования геттеров.
Замечание 2: Ed, мейнтейнер vue-router также советует использовать метаданные путей.
Обработка неавторизованных сценариев
…но подождите. Что делать, если срок действия токена истек, или пользователь не авторизован?
Не беспокойтесь. Используя Axios, мы можем перехватывать все ответы и ответы об ошибке. Для этого необходимо проверять все ответы, и если статус ответа 401 — делаем выход из приложения.
Вот и все, все рады!
Заключение
Данная статья может дать вам хорошую отправную точку для обработки всех вызовов API в вашем приложении.
Надеюсь это будет полезно для ваших будущих проектов! Если вам интересно узнать как избежать cross-site scripting (XSS) в вашем приложении, читайте мой предыдущий пост.
Основы работы с хранилищем Vuex
Vuex является универсальным хранилищем данных для js фреймворка Vue. Использовать его стоит когда с одними данными должны работать разные компоненты. Чаще всего разработчик сам понимает когда это требуется.
Статья выполняет роль небольшой подсказки по функционалу Vuex. Для детального изучения рекомендуем обратиться к официальной документации. В примерах подразумевается что в проекте используется компонентный подход.
Установка может осуществляться несколькими способами:
На практике часто ставят готовую сборку vue-cli с этим дополнением.
Далее в проекте создают каталог store с файлом index.js внутри. В нем можно создавать модель данных, но на практике в контейнере часто хранят данные разной направленности. Поэтому рекомедуется разбивать всё на модули. В этом случае index.js будет содержать примерно следующее:
Пустое хранилище модуля chat.js будет выглядеть так:
Взаимодействие компонентов с vuex
State
Chat — наименование модуля хранилища. Если модульный подход для Vuex не используется, то пишется просто this.$store.state.msg
Теперь в компоненте можем вывести все сообщения из контейнера:
Если в хранилище много полей, то использовать привязку данный из vuex к нашему компоненту так, будто это его собственные данные:
Getters
Mutations
Особенностью Vuex является невозможность изменения данных state напрямую. Для изменения обязательно нужно вызывать функции из секции mutations и вот как это делается:
Здесь мы вызывали мутацию add_msg и передали ей дополнительный параметр, который представляет из себя объект.
Есть и ещё один подход к работе с Vuex. Он заключается в привязке хранилища к компоненту так, будто они принадлежат самому компоненту:
Actions
Вызов действий по синтаксису похож на мутации, но стоит помнить что они могут быть асинхронны, а мутации — нет.
Если мутации не используются, то mapMutations можно удалить. В примере осталось для наглядности как использовать их совместно.
# Что такое Vuex?
Эта документация для Vuex 3, который работает с Vue 2. Документация для Vuex 4, который работает с Vue 3 находится здесь
Vuex — паттерн управления состоянием + библиотека для приложений на Vue.js. Он служит централизованным хранилищем данных для всех компонентов приложения с правилами, гарантирующими, что состояние может быть изменено только предсказуемым образом. Vuex интегрируется с официальным расширением vue-devtools
# Что такое «паттерн управления состоянием»?
Давайте начнём с простого приложения Vue, реализующего счётчик:
Это самостоятельное приложение состоит из следующих частей:
Вот простейшее представление концепции «однонаправленного потока данных»:
Однако простота быстро исчезает, когда у нас появляется несколько компонентов, основывающихся на одном и том же состоянии:
Решая первую проблему, придётся передавать одни и те же данные входными параметрами в глубоко вложенные компоненты. Это часто сложно и утомительно, а для соседних компонентов такое и вовсе не сработает. Решая вторую проблему, можно прийти к таким решениям, как обращение по ссылкам к родительским/дочерним экземплярам или попыткам изменять и синхронизировать несколько копий состояния через события. Оба подхода хрупки и быстро приводят к появлению кода, который невозможно поддерживать.
Так почему бы не вынести всё общее состояние приложения из компонентов и управлять им в глобальном синглтоне? При этом наше дерево компонентов становится одним большим «представлением», и любой компонент может получить доступ к состоянию приложения или вызывать действия для изменения состояния, независимо от того, где они находятся в дереве!
Чётко определяя и разделяя концепции, возникающие при управлении состоянием, и требуя соблюдения определённых правил, которые поддерживают независимость между представлениями и состояниями, мы лучше структурируем код и облегчаем его поддержку.
Это основная идея Vuex, вдохновлённого Flux
Если хотите изучить Vuex в интерактивном режиме, попробуйте этот курс по Vuex на Scrimba.
# Когда следует использовать Vuex?
Vuex помогает управлять совместно используемым состоянием ценой привнесения новых концепций и вспомогательного кода. Компромисс, когда кратковременная продуктивность страдает на благо долгосрочной.
Если ещё не приходилось создавать крупные SPA и вы лишь знакомитесь с Vuex, это может показаться многословным и сложным. Всё в порядке — простые приложения могут легко обходиться и без Vuex. Возможно, будет достаточно простого паттерна глобальной шины событий
Flux-библиотеки похожи на очки: вы будете точно знать, когда они вам понадобятся.
Освоение Vuex — с нуля до героя
Привет, Хабр! представляю вашему вниманию перевод статьи «Mastering Vuex — Zero to Hero» автора Sanath Kumar.
Официальная документация Vuex определяет его как паттерн управления состоянием + библиотека для приложений Vue.js. Но что это значит? Что такое паттерн управления состоянием?
Представьте, что вы работаете над большим веб-приложением с сотнями маршрутов и компонентов. Не было бы проще, если бы мы могли хранить все данные, которые нам когда-либо понадобятся в приложении, в одном централизованном хранилище?
Каждый компонент или маршрут внутри нашего приложения будет запрашивать данные из состояния Vuex и передавать измененные данные обратно в состояние.
По сути, состояние Vuex можно рассматривать как единственный источник истины для всего приложения.
Данные хранятся внутри состояния как JSON-объект. Например:
Но как наши компоненты и маршруты могут получить доступ к данным, хранящимся в нашем состоянии? Для этого внутри нашего хранилища Vuex необходимо определить Геттеры, которые будут возвращать данные из хранилища нашим компонентам. Давайте посмотрим, как выглядит простой Геттер, который получает имя из нашего хранилища:
Заметьте, что имя геттера написано заглавными буквами. Это всего лишь рекомендация по стилю кода. Не обязательно следовать ей, если вам это не нравится.
Теперь, когда мы определили геттер для имени, невероятно легко получить значение имени внутри нашего компонента. В приведенном ниже фрагменте представлен код, который позволяет это сделать.
Мы выяснили, как получить данные из хранилища. Теперь посмотрим, как мы можем установить данные в хранилище. Мы определим сеттеры, верно? Кроме того, Vuex-сеттеры именуются немного иначе. Мы определяем Мутацию (Mutation) для установки данных в наше состояние Vuex.
Что еще за payload? Payload — это данные, передаваемые нашей мутации из компонента, совершающего мутацию. Как мы можем это осуществить? Очень просто:
Этот фрагмент кода изменит состояние приложения и установит любое значение, присвоенное your_name, для свойства name внутри нашего хранилища.
Представьте, что у нас есть список имен, хранящихся в базе данных на удаленном сервере. Сервер предоставляет нам эндпоинт, возвращающий массив имен, которые могут быть использованы в нашем приложении Vue.js. Конечно, мы можем использовать Axios, чтобы сделать запрос к эндпоинту и получить данные.
После этого мы можем передать возвращенный массив в наш магазин состояние Vuex с помощью мутации. Легко, правда? Но не совсем. Мутации являются синхронными, и мы не можем запускать асинхронные операции, такие как вызовы API, внутри мутации.
Что нам в таком случае делать? Создавать Действия (Actions).
Действия подобны мутациям, но вместо того, чтобы напрямую изменять состояние, они совершают мутацию. Звучит запутанно? Давайте посмотрим на объявление действия.
Мы определили действие с именем SET_NAME, которое принимает контекст и payload в качестве параметров. Действие совершает мутацию SET_NAME, созданную ранее, с переданными ей данными, то есть your_name.
Теперь вместо того, чтобы вызывать мутацию напрямую, наши компоненты запускают действие SET_NAME с новым именем в качестве данных следующим образом:
Затем действие инициирует мутацию с переданной ей данными, то есть your_name.
Но почему?
Возможно, вам интересно, почему требуется объявление действия, если мы можем просто инициировать мутации с новым значением непосредственно из наших компонентов. Как упоминалось выше, мутации являются синхронными, а действий — нет.
В приведенном выше примере рассмотрен случай, когда вам нужно обновить значение имени, но не только в своем состоянии, а еще и в базе данных, запущенной на удаленном сервере. Я уверен, что именно так вы собираетесь использовать Vuex в реальном проекте в 99% случаев. Взгляните на следующий фрагмент кода:
Сам код не требует пояснений. Мы используем Axios для отправки имени на эндпоинт. Если POST-запрос выполнен успешно, и значение имени поля было успешно изменено на сервере, мы инициируем мутацию SET_ NAME для обновления значения имени внутри нашего состояния.
ВОЗЬМИТЕ ЗА ПРАКТИКУ НИКОГДА НЕ ИНИЦИИРОВАТЬ МУТАЦИИ НАПРЯМУЮ. ДЛЯ ЭТОГО ВСЕГДА ИСПОЛЬЗУЙТЕ ДЕЙСТВИЯ.
Настройка хранилища Vuex во Vue.JS
Давайте погрузимся глубже и узнаем, как мы можем реализовать Vuex в реальном приложении.
Шаг 1. Установка Vuex
Шаг 2. Создание хранилища Vuex
Шаг 3. Добавление хранилища Vuex в приложение Vue.JS
1. Импортируйте хранилище в файл main.js:
2. Добавьте хранилище к экземпляру Vue, как показано ниже:
Теперь мы можем добавить переменные состояния, геттеры, мутации и действия в наше хранилище Vuex.
Пример
Взгляните на хранилище Vuex простого приложения списка дел. “Только не очередной список дел. ”. Да? Не волнуйтесь. По окончанию данной статьи вы научитесь использовать всю силу и мощь Vuex.
Добавление нового элемента в список дел
Внутри вашего компонента инициируйте действие SAVE_TODO, передав в него новый элемент списка дел, как показано в фрагменте кода ниже.
Действие SAVE_TODO делает POST-запрос к эндпоинту, а затем инициирует мутацию ADD_TODO, которая добавляет элемент списка дел в переменную состояния todos.
Получение элементов списка дел
Внутри блока mounted() вашего компонента инициируйте второе действие GET_TODO, которое получает все элементы списка дел из эндпоинта и сохраняет их в переменную состояния todos, инициируя мутацию SET_TODO:
Доступ к элементам списка дел внутри компонента
Чтобы получить доступ к элементу todos внутри компонента, создайте вычисляемое свойство:
Внутри компонента вы можете получить доступ к вычисляемому свойству:
Использование метода mapGetters
Существует еще более простой способ доступа к элементам списка дел внутри компонента с помощью метода mapGetters, предоставляемого Vuex.
Возможно, вы уже догадались, что код внутри шаблона должен быть изменен, как показано в приведенном ниже фрагменте.
Обратите внимание, как мы использовали оператор распространения ES6 [. ] внутри наших вычисленных свойств.
ХРАНИЛИЩЕ VUEX НЕ ПРОСТО ИСТОЧНИК ТЕКУЩЕГО СОСТОЯНИЯ ВАШЕГО ПРИЛОЖЕНИЯ. ОНО ТАКЖЕ ЯВЛЯЕТСЯ ЕДИНСТВЕННОЙ ТОЧКОЙ, КОТОРАЯ ДОЛЖНА ИЗМЕНЯТЬ ЭТО СОСТОЯНИЕ.
Это требует небольшого объяснения. Мы уже научились создавать действия для получения и установки элементов списка дел в нашем хранилище. Что делать, если нам нужно обновить элемент и пометить его? Где мы запускаем код для этого?
В Интернете вы можете найти различные мнения на этот счет. В документации также нет четких указаний касаемо этого.
Я бы рекомендовал хранить все вызовы API внутри действий в вашем хранилище Vuex. Таким образом, каждое изменение состояния, происходит только внутри хранилища, тем самым облегчая отладку и упрощая понимание кода, а также делает редактирование кода более легким.
Организация кода
Сохранение всех переменных состояния, геттеров, действий и мутаций в одном файле быстро сделает его громоздким, как только вы начнете работать с большими приложениями. Давайте посмотрим, как можно организовать хранилище в нескольких файлах в виде модулей.
Создайте новую директорию внутри вашего хранилища и назовите ее modules. Добавьте в созданную директорию файл todos.js, содержащий следующий код:
Теперь мы можем переместить переменные состояния, геттеры, мутации и действия из файла index.js в файл todos.js. Не забудьте импортировать Axios. Все, что нам нужно сделать, это дать знать Vuex о том, что мы создали модуль хранилища и где его можно найти. Обновленный файл index.js должен выглядеть примерно так:
Файл todos.js будет выглядеть так:
Резюме
Vuex делает работу с Vue намного проще и веселее. Если вы новичок, могут возникать ситуации, когда вам сложно решить, нужно ли использовать Vuex в определенных областях вашего приложения. Следуйте своему инстинкту. Вы достигнете высокой скорости довольно быстро.