lolrofl01

Работал с Nuxt в сумме примерно в течение года. Написал свой блог на нем (довольно большой), вот он на гитхабе: https://github.com/iliyaZelenko/blog-frontend

Недостатки которые заметил:

1) Он долго запускается при `nuxt dev` (мой блог запускается за 3-5 минут) и HMR обновляется в среднем 1-5 секунд (порой и дольше), даже если обновил просто template. Это больше всего напрягает.

2) После изменения кода, иногда папка `.nuxt` генерируется с ошибкой, приходится менять любую строчку в исходниках проекта чтобы опять запустить генерацию или порой полностью перезапускать Nuxt. Такая проблема была замечена не на всех проектах.

3) Бывает проблематично использовать модули которые не идут сразу на сервере и на клиенте, но это больше проблема SSR. Еще порой хочется получить сам nuxt контекст где store, router, плагины, но это нельзя сделать в некоторых местах, обычно эта проблема на клиенте. Например, на клиенте в store где state еще нет свойства window.$nuxt, нельзя обратится к плагину универсальных куков cookie-universal-nuxt и взять из куков значение и записать в state, а по другому к контексту nuxt не обратится. Store тяжело получить в самом store, порой это нужно.

4) Когда с ним использовал TypeScript, то иногда nuxt выдавал что типа (обычно интерфейса) не существует или другие ошибки типов, но этих ошибок на самом деле не было. Единственный выход — заново запускать nuxt dev и долго ждать, порой эта проблема возникала по несколько раз в течении 20 минут, приходилось перезапускать несколько раз.

В моем блоге мне почти всегда нужно было Dependecy Injection чтобы внедрять разные модули, но они были не доступны в `asyncData`, там нет this, пришлось получать прямо из контейнера. Пример кода:

const CategoryRepository = serviceContainer.get<CategoryRepositoryInterface>(TYPES.CategoryRepositoryInterface)

Взят от сюда.

Вообще вместе с vue-class-component нельзя использовать конструктор чтобы внедрять там зависимости, я использовал inversify для DI, но чтобы оно работало vue-class-component пришлось использовать костыль с vue-inversify-decorator (костыльный способ от разработчиков vue-class-component исправить эту проблему), писать `@Provide(container)` в layouts/default.vue (лучшего места не нашел к сожалениию, это тоже минус). Как было бы удобно если внедрил зависимости в конструктор и они сразу есть во всем компоненте и в `asyncData`.

Хочу изучить next (react) чтобы было с чем сравнить.

Во-первых, событие должно быть input, а не change. Во-вторых, нативные события, и события, которые генерирует jquery (на них vue, очевидно, плевать) - это не одно и то же. Так что

$('#dateStart').trigger('change');

следует заменить на что-то вроде

this.dispatchEvent(new Event('input'));

UPD. Пара примеров того, как это может выглядеть:

раз - с использованием jquery-ui datepicker
два - с использованием air-datepicker.

var moment = moment();
Проблема в этом. В момент когда вы пишете var moment - глобальная переменная в этом контексте забывается и появляется локальная. Соответсвенно, когда вы делаете = moment() - он обращается не к глобальной переменной, которую создала библиотека, а к локальной, которую вы создали только что

Просто уберите эту строку и всё должно работать:
var moment = moment();

Как вариант можно сделать общую таблицу transport, содержащую поле name для всех видов транспорта. А ваши таблицы подключать к общей через join по необходимости.

В этом случае поиск будет намного быстрее и проще. И только по одной таблице.

Нагрузка будет зависит от алгоритмов и ПО которое вы используете. Так что на счёт нагрузки, как вы заметили, сложно дать однозначный ответ.
Необходимо правильно написать алгоритм для поиска. Желательно хотя бы 3-4 буквы начал искать. Это зависит от ваших потребностей. Так же нужно сделать так, что бы пользователь сначала ввёл нужные данные (буквы), и только с небольшой задержкой начался поиск.
Так же есть специальные модули/движки (называют по разному) для поиска (сфинкс и т.п.) (В этом не шарю). Которые оптимизированы под такие задачи.

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

в реальности: 50-100 человек отправляющих одновременно запросы - не проблема для любого современного сервера. конечно, если код не писали распоследние слоупоки.

На виртуальном диске virtualbox и лежит - файлы виртуалки бэкапь и все.

Если конечно диск не сделал в отдельную папку.
Там от силы гигов 6 будет или еще меньше

Эластик это не база данных и таблиц там нет. Ну так, чтобы вы совсем в шок впали

Проблема в том, что внутри function своя область видимости и this внутри этой функции - это не тот же самый this, который выше.
Замените

.then(function (res) {
    this.enable = true;
})

на

.then(res => {
    this.enable = true;
})

Ну так ведь выборка из комментов знать не знает ничего про модель юзерс.

Стройте отношения между моделями и делайте выборку через with() или просто ленивой загрузкой.

Этот джоин тут совершенно не нужен в сыром виде.

Пробовал указать и a.href и a.getAttribute('href') и т.д.

Лучше бы попробовали документацию почитать.

@click.prevent="toPage"

toPage(e) {
  console.log(e.target.href)
}

Любой Cat5+.

Чтобы работало долго и выдерживало деформации - не берите омедненный алюмин. Чтобы работало быстро - берите восьмижильный. Остальные параметры, типа сечения жил на таком расстоянии особой роли не играют, намного важнее качественно обжать. Про категории можно в википедии почитать.

1) Если задача первого роутера только раздавать инет, то да, абсолютно любой, даже 4 жильный . Это если вам хочется 1гбитс скорости между роутерами, то там иначе думаьт надо.
2) Если не требуется особого хранения - влажность, вывод на улицу и подобного, то выбирайте любой.
3) если кабель будет лежать тупо по полу, и до него домогаться будет кот, то он перегрызет даже очень плотный кабель. Другое дело, что если вам часто надо будет делать передвижения кабеля, то лучше брать в лучшей оплетке и качества, так как самые дешевые, которыми пользуются инет провайдеры - ломаются на раз два при легком изгибе.

p.s. в годах так 2000-2006 локальные сети районные делали на витых парах, какие попадутся. И ничего, все работало. Сейчас то нет проблем вообще купить кабель. Так что покупайте тот, на который денег хватает. Я для дома себе 100м купил хорошего, порезал на все хотелки, которые хотел, еще и до соседа провел (~40-50 метров через подъезд).
ps2 И кабель можно найти дешевый на авито у вас в городе. Его там полно и дешевле чем в магазинах.

Разумеется одножильник из чистой меди. Да, он будет дороже, чем омедненка, но он будет работать , а не притворяться, что работает. Расстояние небольшое. Если пойдет по улице, берите для внешней прокладки. Если имеются грызуны - придется еще на бронерукав потратится - даже обычная мышка сгрызает куда более плотные вещи.