И усложняет

А я хотел все упростить

Кек

Лол вай

Куда едешь кст

Скажу когда приеду

Если приеду

я заметил

хз что за i18n

Надеюсь из снг валишь

Я б не против))

Я тож на днях пойду визу продлю

хз что за i18n

либа для локалки в nuxt

Мне до Вильнюса 1.5ч езды

От туда самолеты по 15$

По миру

Нормич

Белоруский лайфхак

либа для локалки в nuxt

добавил ее в модули ?

Белоруский лайфхак

Флудим мы только

добавил ее в модули ?

ну да

ну да

хз нужно смотреть тогда, думать я полного кода не вижу )

скинь код

чего именно

чего именно

редиректа

может я зря вообще туда полез

куда ?

может не через мидваре?

просто у меня сейчас пока так

может не через мидваре?

хз

может не через мидваре?

а localePath куда ведет ?

какой формат ссылки

?

а localePath куда ведет ?

https://nuxt-community.github.io/nuxt-i18n/basic-usage.html#nuxt-link

localePath – Returns the localized URL for a given page.

стой я кажись чутка не так делал

app.i18n.localePath

может так ?

ага

app.i18n.localePath

не сработало и все упало) наверное там другой маршрут.

логни app и посмотри в браузере

ага

найди там i18n

ахахах, теперь уже и app не логается

https://codesandbox.io/s/kk9vr4yv4v

спасибо, щас пробую эспеременитровать с 3 полями. но уже третье не получается

Неужели из 4 тыщ народу никому шабашка на пару дней не нужна? Вилка $80-150, бэк лара пилится, фронт нужен качественный, не спа, дизайн есть

Неужели из 4 тыщ народу никому шабашка на пару дней не нужна? Вилка $80-150, бэк лара пилится, фронт нужен качественный, не спа, дизайн есть

я не миддл но сделать смогу запросто

Неужели из 4 тыщ народу никому шабашка на пару дней не нужна? Вилка $80-150, бэк лара пилится, фронт нужен качественный, не спа, дизайн есть

готов работать ?

шабашка на пару дней = неделя. не факт но у меня всегда было именно так.

Неужели из 4 тыщ народу никому шабашка на пару дней не нужна? Вилка $80-150, бэк лара пилится, фронт нужен качественный, не спа, дизайн есть

150$ за фронт? ты с какой деревни такие цены взял?

Не, неделя не

у меня было так. - да там хуйня... - а можно тут поменять?...

сделать так чтобы в браузере загрузился

150$ за фронт? ты с какой деревни такие цены взял?

Было бы много фронта...

Пиши в лс, чё там у тебя

150$ за фронт? ты с какой деревни такие цены взял?

Это же 9к

Неужели из 4 тыщ народу никому шабашка на пару дней не нужна? Вилка $80-150, бэк лара пилится, фронт нужен качественный, не спа, дизайн есть

Гоу ридонли ?

Это же 9к

Там от 80$

Народ подскажите кто знает есть чат. синхронизация с бекендом по сокетам планируется (singalR) вопрос такой. Отправляемое сообщение содержит id юзера и сообщение. я вызываю мутацию в сторе Vuex, сообщение добавляется. Одновременно я подписался на приход новых сообщений. Для рендера компонента сообщения требуются данные юзера такие как аватарка, его nickname; когда в шаблоне вывожу в цикле компоненты сообщения я прохожусь по массиву сообщений из стора, смотрю если айдишка в объекте пришедшего сообщения совпадает с моей айдишкой - выводить данные из модуля user (там данные текущего юзера) а если не совпадает то тут есть варианты: Если отправлять запрос на сервер getUserById и оттуда выдёргивать что мне надо, то это мне надо делать при каждом приходе нового сообщения. Есть вариант проверять перед запросом есть ли юзер в псевдообъекте всех закешированных юзеров в localstorage, если есть - брать данные оттуда, если нету - запрос на сервер. Это нормальная практика или есть решения по лучше?

Сначала было нормально, а потом бах. Концовка неожиданная

ну мнебекендер говорит кешировать некритическую инфу) может я неверно понял задачу(

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

а если в сторе хранить логику того сколько держать придумывать не нужно?) скажем в чате мы общаемся с 1 пользователем закешировали его аватарку и никнейм перешли на страницу поиска юзеров всех юзеров в списке также кешировать будем? перешли в профиль юзера - такие данные как статус онлайн, что сейчас делает, кол-во друзей (динамическое) кешировать не надо аватарку закешировали если а он сменил - мы её и не увидим новую получается..

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

ERROR: S client not available

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

Ну так и кешируй

А если обновляешь инфу то дергай ручки за инфой на сервер

Ну так и кешируй

создать поле cachedUsers скажем в модуле App стора и туда пушить после всякого запроса весь объект с юзером?

а если в сторе хранить логику того сколько держать придумывать не нужно?) скажем в чате мы общаемся с 1 пользователем закешировали его аватарку и никнейм перешли на страницу поиска юзеров всех юзеров в списке также кешировать будем? перешли в профиль юзера - такие данные как статус онлайн, что сейчас делает, кол-во друзей (динамическое) кешировать не надо аватарку закешировали если а он сменил - мы её и не увидим новую получается..

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

оверхед минимальный, гоняешь лишних 100 байт, максимально кэшируешь и обновляешь по необходимости

оверхед минимальный, гоняешь лишних 100 байт, максимально кэшируешь и обновляешь по необходимости

то есть условно первый раз как чат открыл и пришло событие от сервера с сообщением от айдишки которой нету в кеше- загоняю в кеш и в updated_at ставлю new Date() где я буду это поле использовать? в чате когда пишу и мне снова юзер ответил я беру данные из кеша но в чате мне не критично смотреть его динамические данные как статус онлайна (он априори в чате когда - онлайн) а вот если перехожу в профиль мне получается нужно вызывать экшн но с параметром каким-нить который игнорирует прписанную в нём проверку на существование кеша? опять же где юзать updated_at? Вопросы может глупые, новичек в этом деле)

то есть условно первый раз как чат открыл и пришло событие от сервера с сообщением от айдишки которой нету в кеше- загоняю в кеш и в updated_at ставлю new Date() где я буду это поле использовать? в чате когда пишу и мне снова юзер ответил я беру данные из кеша но в чате мне не критично смотреть его динамические данные как статус онлайна (он априори в чате когда - онлайн) а вот если перехожу в профиль мне получается нужно вызывать экшн но с параметром каким-нить который игнорирует прписанную в нём проверку на существование кеша? опять же где юзать updated_at? Вопросы может глупые, новичек в этом деле)

Зачем тебе делать new Date()? Получаешь объект с сервера, сохраняешь. Он тебе шлёт вместо всего профиля пользователя updated_at - оно всегда в БД есть. А ты у себя сравниваешь везде, где тебе нужно. Получил разницу - отправляешь полный запрос на нужные данные и присваиваешь

Зачем тебе делать new Date()? Получаешь объект с сервера, сохраняешь. Он тебе шлёт вместо всего профиля пользователя updated_at - оно всегда в БД есть. А ты у себя сравниваешь везде, где тебе нужно. Получил разницу - отправляешь полный запрос на нужные данные и присваиваешь

"Он тебе шлёт вместо всего профиля пользователя updated_at - оно всегда в БД есть." кто и когда мне шлёт? при открытии чата я первый раз должен прогрузить данные по юзеру отправив запрос на ендпоинт /users/ID тут полная инфа о нём, профиле и прочей ерунде её я пушу в store.app.users дальше я закрыл чат и перехожу в профиле к этому же пользователю мне отправлять запрос надо на тот же ендпоинт для получения актуальных данных другое дело что я не перезапишу если поле updated_at тоже что и у меня в кеше но запрос то надо делать всегда

"Он тебе шлёт вместо всего профиля пользователя updated_at - оно всегда в БД есть." кто и когда мне шлёт? при открытии чата я первый раз должен прогрузить данные по юзеру отправив запрос на ендпоинт /users/ID тут полная инфа о нём, профиле и прочей ерунде её я пушу в store.app.users дальше я закрыл чат и перехожу в профиле к этому же пользователю мне отправлять запрос надо на тот же ендпоинт для получения актуальных данных другое дело что я не перезапишу если поле updated_at тоже что и у меня в кеше но запрос то надо делать всегда

1. У тебя должно быть 2 типа запросов - 1) короткие, которые ты гоняешь постоянно и 2) полные, которые тянут всю информацию и обновляют. Как это будет реализовано - на ваш выбор. Можно отправлять info: 1, когда надо получить полный запрос, и не отправлять его, когда получаешь лёгкую версию. Можно сделать отдельные экшены для коротких запросов.

Короткий запрос просто возвращает тебе updated_at, ты его сравниваешь со своим

Есть разница - отправил запрос с info: 1

Это же REST, сервер не знает, обновлены у тебя данные или нет, такие же они или различаются.

Можешь гонять данные целиком - но будет непродуктивно по траффику

Нужен запрос, который возвращает короткие данные про юзера (имя, аватар, допустим). Ну и его гонять. Чат-то однопользовательский или многопользовательский?

в том и прикол что тут не классический REST, тут двустороннняя синхронизация стора будет но часть вещей неудобно формировать на бекенде так как он на C# и дублирует сущности которые можно было бы получить по ендопоинту, но дескать сделать это надо с экономией трафика и нагрузки на сервер. Чат пока что однопользовательский я вообще предложил бекендеру чтоб ему отправлялся экшн с данными: дата сообщения, userId, userName, userAvatar он получае эти данные и у себя вызывает аналогичное по имени экшна событие сокета на которое я и все клиента подписаны в миддлваре по итогу другому юзеру диспатчится экшн с уже готовыми данными для шаблона которых я тупо юзаю перебором в цикле Messages а если там тупо id-—шка то мне надо ещё и запрос мутить но не каждый же раз при поступлении сообщения вот и задался вопросом как кешировать хорошо)

в том и прикол что тут не классический REST, тут двустороннняя синхронизация стора будет но часть вещей неудобно формировать на бекенде так как он на C# и дублирует сущности которые можно было бы получить по ендопоинту, но дескать сделать это надо с экономией трафика и нагрузки на сервер. Чат пока что однопользовательский я вообще предложил бекендеру чтоб ему отправлялся экшн с данными: дата сообщения, userId, userName, userAvatar он получае эти данные и у себя вызывает аналогичное по имени экшна событие сокета на которое я и все клиента подписаны в миддлваре по итогу другому юзеру диспатчится экшн с уже готовыми данными для шаблона которых я тупо юзаю перебором в цикле Messages а если там тупо id-—шка то мне надо ещё и запрос мутить но не каждый же раз при поступлении сообщения вот и задался вопросом как кешировать хорошо)

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

Тот же ВК, например, гоняет запросы каждые несколько секунд

Которые чекают новые сообщения, чекают запросы, новости и уведомления

ну у нас signalR - там сокеты

шлёшь message/:id сравниваешь updated_at, если есть изменения шлёшь запрос и получаешь сообщения, у себя локально добавляешь в массив, например.

там соединение открыто и не надо в сетинтервале слать запросы) как что-то изменилось в сторе - триггерится такое же событие у соединения на которое одновременно оформлена подписка результатом срабатывания которой является мутация в сторе

чуваки, кто там с PiterJs

голосовалка кривая, доклады не те

шлёшь message/:id сравниваешь updated_at, если есть изменения шлёшь запрос и получаешь сообщения, у себя локально добавляешь в массив, например.

спасибо) буду пробовать) тяжко всё это после 5 лет верстки лендосов)

там соединение открыто и не надо в сетинтервале слать запросы) как что-то изменилось в сторе - триггерится такое же событие у соединения на которое одновременно оформлена подписка результатом срабатывания которой является мутация в сторе

Ну тогда не знаю, у нас бэкенд везде на yii2, я с фронтом работаю и начал ковырять ноду, поэтому с сокетами не работал ещё.

Народ подскажите кто знает есть чат. синхронизация с бекендом по сокетам планируется (singalR) вопрос такой. Отправляемое сообщение содержит id юзера и сообщение. я вызываю мутацию в сторе Vuex, сообщение добавляется. Одновременно я подписался на приход новых сообщений. Для рендера компонента сообщения требуются данные юзера такие как аватарка, его nickname; когда в шаблоне вывожу в цикле компоненты сообщения я прохожусь по массиву сообщений из стора, смотрю если айдишка в объекте пришедшего сообщения совпадает с моей айдишкой - выводить данные из модуля user (там данные текущего юзера) а если не совпадает то тут есть варианты: Если отправлять запрос на сервер getUserById и оттуда выдёргивать что мне надо, то это мне надо делать при каждом приходе нового сообщения. Есть вариант проверять перед запросом есть ли юзер в псевдообъекте всех закешированных юзеров в localstorage, если есть - брать данные оттуда, если нету - запрос на сервер. Это нормальная практика или есть решения по лучше?

statless state или как то так, запрос должен кешироваться

statless state или как то так, запрос должен кешироваться

что вы этим хотите сказать? я юзаю axios

Т.е. ты его запрашиваешь и если он был уже однаётся локально, нет идёт запрос к серверу, и есть даже техники батчить их, т.е. в группы объеденять, не по 1 на юзера а сразу кучей

что вы этим хотите сказать? я юзаю axios

В vuex же

Юзер то не меняется со временем ...

На то оно и состояние )

ну у нас юзеров куча может быть например в результатах поиска по параметрам нам запрос нужен для получения кратких данных нужных для шаблона получать все данные и пушить их в стор в раздел cachedUsers не вижу смысла при том что юзер текущий ими может тупо не воспользоваться, а трафик на это потратить больше чем надо но если бекендер не сделает норм апишку то придётся)