Pull to refresh
2
0
Send message
Я вам сейчас расскажу как такое сатанинство происходит.

Сидят нищие пенсионеры, смотрят господина Соловьева, услышали кодовую фразу «Дуров, телеграм, терорристы» и легли спать. Утром выходят на лавочки, обсуждают всякое из новостей и через какое-то время приходят общей повестке дня. В течение пару часов накручивают сами же себя до неистового состояния, еще через пару часов воплей пара самых продвинутых уже прибегает с распечатанными внуком листовками, истерия нарастает. Апогеем являются вот такие видосы.

Через пол часа уставшие и довольные победой над мировым терроризмом
и главным на сегодня врагом России Дуровым пенсионеры идут домой пить корвалол. Завтра новая повестка дня, новый Дуров и новые победы.

Враг не пройдет.
UX — удобно, UI — красиво.
Любой пользователь — а это действующий или потенциальный ученик — взаимодействует не с «голым» кодом, нейросетями и методиками, а с контентом. И от качества этого контента напрямую зависит интерес к обучению.

На этой капитанской ноте надо было заканчивать статью.
Обычно саму страницу никто «жестко» (с Cache-Control: max-age) кэшировать не станет
Зависит от сценария, который реализуется. Как правило при первом обращении кэшируется вся статика необходимая для работы сайта/приложения и какой-то список страниц: rg.ru последние N новостей и показывает плашку «Ой! У вас нет интернета.», видел магазин который клал в кэш сразу все инфо страницы, сайт рекламного агентства — страницы оферов и их описаний.
Неправда. Если файл уже закэширован браузером после первого запроса, то последующие запросы к нему выполняются без сети.

Ключевое здесь файл. Статика. В случае кэширования в cacheStorage можно положить text/html response. При чем положить заранее, при первом обращении к серверу. При чем respone на любой request.url. То есть фактически при первом обращении задать список доступных оффлайн страниц.
В случае кэширования в cacheStorage (не обязательно в service-worker, оно доступно и для window) при отправке запроса на серв не нужно получать заголовок — можно перехватить, проверить на какой ресурс запрос, и отдать соответствующий response из cacheStorage. И все это локально. На клиенте. Потому что раньше предусмотрительно положили туда нужные пары request-respones. Поэтому если клиент оффлайн, pwa'шка может отдавать соответствующий response без обращения к серверу. В этом и суть оффлайн pwa. Запросы не уходят в сеть. А чтобы получить заголовок кэширования обычными методами серва, нужна сеть.
Нет, не SPA, обычное PWA которое прикручивается к обычному интернет-магазину с обычным php на бэкенде. Контент в SW делится на imgCache, staticCache и contentCache.

Во время сёрфинга по сайту в contentCache пишется text/html и соответственно при cacheFirst отдается из кэша. Так вот именно его нужно обновлять при определенных действиях: добавили в корзину, удалил, добавил в избранное, к сравнению, лайк\дизлайк, оставил комментарий. Потому что он хранит контент до этих действий. Надеюсь так понятнее :)

И вот такой костыль решает задачу, но чувствую что есть нативное решение.
function updateCacheByName (cacheName,updateRequestsArray) {
caches.delete(cacheName)
.then(function(){
console.log('удалили кэш '+cacheName+' чтобы обновить');
caches.open(cacheName).then(cache => {
return cache.addAll(updateRequestsArray).then(function(){
console.log('история обновлена в кэше '+cacheName);
}).catch( err => {console.log(err);});
});
}).catch( err => {console.log(err);});
}
Нужна статья о синхронизации и фоновом обновления кэша. Например когда используется cacheFirst и кэшируется вообще все. Статику понятно, можно версионированием кэшей контролировать, а вот с контентом пока только костыли использовал. Например пользователь из листинга ушел в карточку товара, там добавил его в корзину, возвращается на листинг, а ему отдает версия страницы из кэша в которой корзина пустая. Делал для этого historyArr[] в котором хранил все request.url и при определенном запросе на сервер обновлял contentCache чтобы контент всегда был актуальный, но так как немношк не разраб, чувствую что костыль не оч верный и есть нативная синхронизация для подобных вещей.
Мне начинает казаться что у вас разговор слепого с глухим: вы ему о СТО и пастулате невозможности сверхсвета в вакууме, он про черенковское излучение в средах и что там есть сверхсвет :)
Нет, но в вашей вселенной пусть будет так.
Я все прекрасно понимаю. Пример как раз для тех, кто «ну а что если предположить сверхсвет, то что?» А вот что, если получится нарушить законы физики, то на графике угол станет тупым и система начнет движение к началу координат, в обратном направлении во времени.
Как и никто не ожидал прочитать что математика лишь описывает наблюдаемое.
Математика лишь описывает наблюдаемое.

што?
Это при 90°. Двигаясь по (x,y,z) под большим углом (сверхсветовой скоростью) по оси времени (Y), система будет двигаться к началу координат по этой оси.
Проще всего объяснить невозможность сверхсветовой скорости как: скорость света, фотона в вакууме, равна скорости течения времени. Поэтому время для фотона останавливается. На сетке (t,(x,y,z)) угол между осями для фотона будет 90°. Будет угол >90°, будет перемещение в прошлое.
Если провести чистый эксперимент то никак не отличите находитесь ли вы в кресле на Земле или движетесь в кресле по орбите с ускорением g.
Не мешает конечно же, но растягивает во времени.
Например научился кодить на 5-7, пришло время курить оптимизацию, и тут ты на 7 ступени начинаешь постигать базу, переосмысливать подходы к решению задач.
Знай вы такой расклад заранее, согласились бы что начинать с базы (в ВУЗе или нет неважно) оно все же оптимальнее?

Сортировки и обходы примерно 1-2 ступень, 1-3 семестр.
Наверное вы правы.
Имел ввиду что путь от 0 до 10 где 10 хороший кодер, в ВУЗе начинается именно с 0, а при самообразовании а-ля «спросил-закодил» где-то с 3-4 ступени пропуская базовые 0-2. Потому что тупо не знаешь об их существовании или задаешь не те вопросы.
Ну и да, самообразование может быть и с 0.
1

Information

Rating
Does not participate
Registered
Activity