Comments 20
Не будет нормальной типизации с Vuex, и все библиотеки для его типизации костыли. Выкинь его. Как? Берешь что-то вроде { ModuleName: Vue.observable(new MyStorageModuleName()) } и запихиваешь как плагин и/или даже в window.$myStorage.
Выходит действительно хорошо, использую такой подход на продакшене второй год. Vuex собираюсь откапывать для новых проектов только в 5-ой версии, где они обещали все с нуля переписать с нормальной поддержкой ts.
Алсо класс-синтаксис компонентов самому очень нравится, но, наверное, от этого надо уходить, для vue 3 его почти похоронили
Нет ничего плохого, чтобы использовать такие библиотеки для типизации. В статье есть ссылка на еще 6 подобных библиотек, и все они лучше, чем навешивать модули на window. У нас в продакшене больше 20 модулей, все на window не навесишь.
А ждать 5 версию vuex — ожидание может затянуться, так что в проде вашу идею я бы не рекомендовал использовать на больших проектах.
Да, класс-синтаксис это большой помощник в типизации компонентов, сам очень доволен.
Следует избегать расширения прототипа. Глобальный объект тоже вариант плохой (ну может быть только в целях дебага). При Вашем подходе лучше уж бросить объект через provide/inject
Тоже к чему-то подобному пришёл. Во всех новых проектах vuex не использую. По ощущению сам vuex и есть костыль
mix.js('resources/js/app.ts', 'public/js')
.sass('resources/sass/app.scss', 'public/css')
.webpackConfig({
module: {
rules: [
{
test: /\.tsx?$/,
loader: "ts-loader",
options: {
appendTsSuffixTo: [/\.vue$/]
},
exclude: '/node_modules/',
}
]
},
resolve: {
extensions: ["*", ".js", ".jsx", ".vue", ".ts", ".tsx"]
}
})
.version();
if (mix.inProduction()) {
mix.version();
}app.vue переименовал в app.ts
добавил vue-shim.d.ts
declare module "*.vue" {
import Vue from 'vue'
export default Vue
}А в компонентах так:
<script lang="ts">
import Vue from 'vue';
import {AmoApiSettings} from "../../types/types";
interface Data {
settings?: AmoApiSettings,
integration_id?: string
is_loaded: boolean,
}
export default Vue.extend({
name: "Amo",
data: function (): Data {
return {
settings: undefined,
integration_id: undefined,
is_loaded: false,
}
},
});
</script>Но в статье я хотели привести пример интеграции Vuex c типизацией внутрь компонентов, чтобы типизация вашего store работала внутри компонентов (включая dispatch, getters, commit и сам state).
Также рекомендую посмотреть class components — там чуть проще настраивать типизацию внутри компонентов, попробуйте
Извините, вопрос не по теме. Но может Вы подскажите в чем проблема.
Пару недель назад решил изучить и попробовать Vue в связке с Laravel (до этого SPA не делал) на одной из форм админки. Форма там сложная, надо в кучу данных собрать из 11-и таблиц с репитерами c взаимосвязанными селектами и вывести предварительные расчеты на фронте.
В шаблон блейда добавил токен в хедер
<meta name="csrf-token" content="{{ csrf_token() }}">Прописал родительский тег
<div id="app-operation"></div>и подключил в футер собранный скрипт
В самом скрипте прописал автоматом передачу CSRF-токена
window._ = require('lodash');
window.axios = require('axios');
window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';
window.axios.defaults.headers.common['X-CSRF-TOKEN'] = document.querySelector('meta[name="csrf-token"]').getAttribute('content');
window.Vue = require('vue');
const app = new Vue({router,store,components: {App},render: h => h(App)
})
app.$mount('#app-operation')И вот из стора дергаю API. При загрузке формы там уходит сразу 7-м запросов (стоит их наверное объединить) и периодически один из них отвечает 422 статусом с ошибкой: No application encryption key has been specified.
Причем это происходит случайным образом (по крайней мере я не нашел фактора который на это влияет) для разны GET API и как правило только один запрос с ошибкой, остальные (предыдущие и последующие) -200. Просмотрел, у всех запросов одинаковые хедеры.
Все роуты для этих ajax прописаны в web.php.
Google естественно дает ответы только на то как сгенерировать key. Пока вижу решение просто делать повторный запрос, но как-то оно костыльно.
Подскажите пожалуйста в какую сторону рыть.
env складываем переменные куда-то в ОС и при много-потокой обработке эти переменные в других потоках не доступны. По крайней мере я находил ишью где у людей схожая проблема. Самое простое это кешировать конфиги. но для локальной разработки не очень удобно, постоянно их обновлять.
Посмотрим, будут ли такие проблемы на серваке, а локально я уж переживу та и давно уже надо перейти в ubuntu хотя бы, а то аж не удобно :)
Динамические импорты компонентов — это по умолчанию, всегда так делайте (это Components: () => import(path)), webpack умный и такие импорты в 90% случаях уменьшат вам время полной загрузки страницы, а в оставшихся 10% — ничего не поменяют, так что оно того стоит. Это просто, одинаково и удобно.
Как уменьшит время полной загрузки?
Всегда в компонентах прописывайте имя (даже с учетом того, что оно опционально).
Какие аргументы?
Старайтесь названия файлов компонентов согласовывать с названием классов (и именами внутри).
Всегда делаю по умолчанию)
Вызовы к api — ТОЛЬКО из store, об этом вам скажет любой Vue разработчик.
Вызов в store — но сами функции складированы в другой директории.
Как уменьшит время полной загрузки?
Lazy loading vue — профит в скорости загрузки бандла, в частности в роутере и в компонентах в которых другие компоненты используются через v-if к примеру. То есть могут не потребоваться при первоначальном показе страницы.
Какие аргументы?
Документация
Вызов в store — но сами функции скадированы в другой директории
Да, вы абсолютно правы! Добавлю, спасибо.
Позволю не согласиться с вами насчёт динамического импорта компонентов. Абсолютно точно не следует его использовать для всех компонентов. Эта штука нужна и полезна в тех случаях, когда часть приложения не всегда используется. Например, пользователь открыл сайт, но компонент с корзиной, скажем, можно загружать динамически, так как пользователю он сразу не нужен. Но если все компоненты грузить динамически, то мы только заставим браузер загружать несколько отдельных более мелких чанков с кодом, что совсем даже не ускорит загрузку, а ровно наоборот.
Что касается типизации — то Vue 3, вообще-то, уже зарелизился ещё осенью, хотя переходить на него рановато, однако использовать плагин @vue/composition-api с vue2 + ts никто не мешает уже сейчас.
Вопросом типизации и управления более-менее большими проектами пришлось недавно озадачиться, в результате родилась пока ещё довольно сырая поделка под названием VueenT, которую можно найти на github. С документацией пока все плохо, но есть исходники и тесты. @vueent/mix-models используем вместо Vuex, но там парадигма другая.
Vue 3 вышел пол года назад! Скоро уже думаю 3.1 будет. Так что первое же предложение в статье — неправда.
Ну и со всем этим обвесом будет весело мигрировать на тройку, класс компоненты больше официально не поддерживаются им на смену пришла композиция.
Я тоже пытался подружить vue 2 с ts. Пришел к аналогичному решению, только ещё смарт модуль форкнул, т.к. там есть проблема с типизацией и автоподстановкой. + ещё какие то библиотеки ставил для чека типов в шаблонах, enums в шаблонах и т.д…
Мой вывод такой:
1) это не идеальная типизация, очень много не поддерживается, много не чекается, положиться на 100% нельзя. По сравнению с реакт миром грусть.
2) зоопарк библиотек/утилит дико раздражает, написаны они не очень, работают нестабильно.
3) декораторы, компонент — классы использовать очень не хочется
4) у меня все это добро вызывает тревогу, а у приходящих в компанию фронтов — панику.
5) итоговый вывод — не стоит оно того, js + jsdoc для vue 2 — оптимальный вариант.
Пока Vue 3 официально еще не вышел
Ничего не понимаю, статья лежала в черновиках полгода и вы её опубликовали без правок?
Идеальное Vue приложение на Typescript