[Из песочницы] Аскетичный вебъ: прототип барахолки на go и js13.01.2019 17:02

Разделы соответствуют типам данных: /#goods, /#posts, /#users.
Параметры: ? id=идентификатор_записи, ? page=номер_страницы, ? search=поисковый_запрос.

Несколько примеров:

• /#posts? id=1542309643&page=999&search={auth: anon} — раздел posts, id поста — 1542309643, страница комментариев — 999, поисковый запрос — {auth: anon}
• /#goods? page=2&search=сиддхартха — раздел goods, страница раздела — 2, поисковый запрос — сиддхартха
• /#goods? search=wer{key: value}t — раздел goods, поисковый запрос — состоит из поиска подстроки wert в заголовке или тексте объявления и подстроки value в свойстве key табличной части объявления
• /#goods? search={model:100, display:256} — думаю тут всё понятно по аналогии

Функции парсинга и формирования урл в нашей реализации выглядят так:

window.addEventListener('hashchange', function() {
  const hash = location.hash.slice(1).split('?'), result = {}
  if (!!hash[1]) hash[1].split('&').forEach(str => {
    str = str.split('=')
    if (!!str[0] && !!str[1]) 
      result[decodeURI(str[0]).toLowerCase()] = decodeURI(str[1]).toLowerCase()
  })
  result.type = hash[0] || 'goods'
  store.set({ hash: result })
})

function goto({ type, id, page, search }) {
  const { hash } = store.get(), args = arguments[0], query = []
  new Array('id', 'page', 'search').forEach(key => {
    const value = args[key] !== undefined ? args[key] : hash[key] || null
    if (value !== null) query.push(key + '=' + value)
  })
  location.hash = (type || hash.type || 'goods') + 
    (!!query.length ? '?' + query.join('&') : '')
}

API

Для обмена данными с сервером будем использовать fetch api. Для загрузки обновлённых записей через небольшие промежутки времени делаем запрос к /pub/mtimes, если время последнего изменения для какого-либо типа отличается от локального, загружаем список этого типа. Да, можно было реализовать уведомление об обновлениях через SSE или WebSocket’ы и инкрементную подгрузку, но в данном случае обойдёмся без этого. Что у нас получилось:

async function GET(type) {
  const response = await fetch(location.origin + '/pub/' + type)
    .catch(() => ({ ok: false }))
  if (type === 'mtimes') store.set({ online: response.ok })
  return response.ok ? await response.json() : []
}

async function checkUpdate(type, mtimes, updates = {}) {
  const local = store.get()._mtimes, net = mtimes || await GET('mtimes')
  if (!net[type] || local[type] === net[type]) return
  const value = updates['_' + type] = await GET(type)
  local[type] = net[type]; updates._mtimes = local
  if (!!value && !!value.sort) store.set(updates)
}

async function checkUpdates() {
  setTimeout(() => checkUpdates(), 30000)
  const mtimes = await store.GET('mtimes')
  new Array('users', 'goods', 'posts', 'cmnts', 'files')
    .forEach(type => checkUpdate(type, mtimes))
}

Для фильтрации и пагинации используем вычисляемые свойства Svelte, основываясь на данных навигации. Направление вычисляемых значений таково: items (массивы записей приходящие от сервера) => ignoredItems (отфильтрованные записи на основе списка игнора текущего пользователя) => scribedItems (отфильтровывает записи по списку подписок, если такой режим активирован) => curItem и curItems (вычисляет текущие записи в зависимости от раздела) => filteredItems (фильтрует записи в зависимости от поискового запроса, если запись одна — фильтрует комментарии к ней) => maxPage (вычисляет количество страниц из расчета 12 записей/комментариев на страницу) => pagedItem (возвращает конечный массив записей/комментариев на основе номера текущей страницы).

Отдельно вычисляются комментарии и изображения (comments и _images), группируясь по типу и записи-владельцу.

Вычисления происходят автоматически и только при изменении связанных данных, промежуточные данные постоянно находятся в памяти. В связи с этим делаем малоприятный вывод — для большого количества информации и/или частого её обновления может расходоваться большое количество ресурсов.

Cache

Согласно решению делать offline-приложение, реализуем хранение записей и некоторых аспектов состояния в localStorage, файлов изображений в CacheStorage. Работа с localStorage предельно проста, договоримся что свойства обладающие префиксом »_» при изменении автоматически сохраняются и восстанавливаются при перезагрузке. Тогда наше решение может выглядеть так:

store.on('state', ({ changed, current }) => {
  Object.keys(changed).forEach(prop => {
    if (!prop.indexOf('_')) 
      localStorage.setItem(prop, JSON.stringify(current[prop]))
  })
})

function loadState(state = {}) {
  for (let i = 0; i < localStorage.length; i++) {
    const prop = localStorage.key(i)
    const value = JSON.parse(localStorage.getItem(prop) || 'null')
    if (!!value && !prop.indexOf('_')) state[prop] = value
  }
  store.set(state)
}

С файлами немного сложнее. В первую очередь воспользуемся списком всех актуальных файлов (с временем создания), приходящим от сервера. При обновлении этого списка сравниваем со старыми значениями, новые файлы помещаем в CacheStorage, устаревшие удаляем оттуда:

async function cacheImages(newFiles) {
  const oldFiles = JSON.parse(localStorage.getItem('_files') || '[]')
  const cache = await caches.open('comico')
  oldFiles.forEach(file => { if (!~newFiles.indexOf(file)) {
    const [ id, type ] = file.split(':')
    cache.delete(`/img/${type}_${id}_sm.jpg`)
  }})
  newFiles.forEach(file => { if (!~oldFiles.indexOf(file)) {
    const [ id, type ] = file.split(':'), src = `/img/${type}_${id}_sm.jpg`
    cache.add(new Request(src, { cache: 'no-cache' }))
  }})
}

Затем нужно переопределить поведение fetch так, чтобы файл брался из CacheStorage без коннекта к серверу. Для этого придётся воспользоваться ServiceWorker’ом. Заодно настроим сохранение в кэш других файлов для работы вне связи с сервером:

const CACHE = 'comico', FILES = [ '/', '/bundle.css', '/bundle.js' ]

self.addEventListener('install', (e) => {
  e.waitUntil(caches.open(CACHE).then(cache => cache.addAll(FILES))
    .then(() => self.skipWaiting()))
})

self.addEventListener('fetch', (e) => {
  const r = e.request
  if (r.method !== 'GET' || !!~r.url.indexOf('/pub/') || !!~r.url.indexOf('/api/')) return
  if (!!~r.url.lastIndexOf('_sm.jpg') && e.request.cache !== 'no-cache') 
    return e.respondWith(fromCache(r))
  e.respondWith(toCache(r))
})

async function fromCache(request) {
  return await (await caches.open(CACHE)).match(request) || 
    new Response(null, { status: 404 })
}

async function toCache(request) {
  const response = await fetch(request).catch(() => fromCache(request))
  if (!!response && response.ok) 
    (await caches.open(CACHE)).put(request, response.clone())
  return response
}

Выглядит немного коряво, но свои функции выполняет.

Клиент / интерфейс

Структура компонентов:
index.html | main.js
== header.html — содержит логотип, строку состояния, главное меню, нижнее навигационное меню, форму отправки комментария
== aside.html — является контейнером для всех модальных компонентов
==== goodForm.html — форма добавления и редактирования объявления
==== userForm.html — форма редактирования текущего пользователя
====== tableForm.html — фрагмент формы для ввода табличных данных
==== postForm.html — форма для поста форума
==== login.html — форма логина/регистрации
==== activity.html — отображает комментарии обращенные текущему пользователю
==== goodImage.html — просмотр основного и дополнительных фото объявления
== main.html — контейнер для основного содержимого
==== goods.html — карточки списка или одиночного объявления
==== users.html — то же для пользователей
==== posts.html — думаю, понятно
==== cmnts.html — список комментариев к текущей записи
====== cmntsPager.html — пагинация для комментариев

• В каждом компоненте мы стараемся минимизировать количество html-тэгов.
• Классы используем только в качестве показателя состояния.
• Схожие функции выносим в стор (свойства и методы svelte store можно использовать напрямую из компонентов добавляя к ним префикс '$').
• Большинство функций ожидают пользовательского события или изменения определённых свойств, манипулируют данными стейта, сохраняют обратно в стейт результат свой работы и завершаются. Таким образом достигается малая связанность и расширяемость кода.
• Для видимой скорости переходов и других UI-событий мы по возможности отделяем манипуляции с данными, происходящими в фоне и действия связанные с интерфейсом, который в свою очередь использует текущий результат вычислений, перестраиваясь при необходимости, остальную работу любезно выполнит фреймворк.
• Данные заполняемой формы сохраняем в localStorage на каждый ввод, чтобы предотвратить их потерю.
• Во всех компонентах используем иммутабельный режим, в котором свойство-объект считается изменённым только только при получении новой ссылки, независимо от изменения полей, таким образом немного ускоряем наше приложения, пускай и за счет небольшого увеличения объёма кода.

Клиент / управление

Для управления с помощью клавиатуры задействуем следующие комбинации:
Alt+s / Alt+a — переключает страницу записей вперёд / назад, для одной записи переключает страницу коментариев.
Alt+w / Alt+q — осуществляет переход ко следующей / предыдущей записи (если таковые существуют), работает в режиме списка, одной записи и просмотра изображения
Alt+x / Alt+z — прокручивает страницу вниз / вверх. В режиме просмотра изображений переключает изображения вперёд циклично / назад
Escape — закрывает модальное окно, если открыто, возвращает к списку, если открыта одиночная запись, отменяет поисковый запрос в режиме списка
Alt+c — фокусирует на поле поиска или ввода комментария, в зависимости от текущего режима
Alt+v — включает / отключает режим просмотра фото для одиночного объявления
Alt+r — открывает / закрывает список входящих комментариев для авторизованного пользователя
Alt+t — переключает светлую / тёмную темы оформления
Alt+g — список объявлений
Alt+u — пользователей
Alt+p — форум
Знаю, во многих браузерах эти сочетания используются самим браузером, однако для моего хрома я не смог придумать что-то удобнее. Буду рад вашим предложениям.

Помимо клавиатуры конечно же можно использовать консоль браузера. Для примера — store.goBack (), store.nextPage (), store.prevPage (), store.nextItem (), store.prevItem (), store.search (stringValue), store.checkUpdate ('goods'||'users'||'posts'||'files'||'cmnts') — делают то что подразумевает из название; store.get ().comments и store.get ()._images — возвращает группированные файлы и комментарии; store.get ().ignoredItems и store.get ().scribedItems — списки игнорируемых и отслеживаемых вами записей. Полный список всех промежуточных и вычисленных данным доступен из store.get (). Не думаю что это всерьёз может кому-то понадобиться, но, к примеру, отфильтровать записи по пользователю и удалить мне показалось вполне удобно именно из консоли.

Заключение

На этом знакомство с проектом можно закончить, больше подробностей вы можете найти в исходных текстах. Как итог у нас получилось довольно быстрое и компактное приложение, в большинстве валидаторов, чекеров безопасности, скорости, доступности и т. п. показывает высокие результаты без целенаправленной оптимизации.
Хочется узнать мнение сообщества насколько оправданно использованные в прототипе подходы к организации приложений, какие могут быть подводные камни, что бы вы реализовали принципиально по-другому?
В частности вопросы: хранение всех данных (кроме паролей) на клиенте, агрессивное кэширование изображений, состояние индексации SPA поисковиками на сегодняшний день (почему PageSpeed правильно парсит приложение, а гугл-робот нет?), актуальность использования hash страницы для навигации, возможные недостатки in-memory noSQL в подобного типа проектах (и buntDB в частности), проектирование интерфейса для гиков (без лишних подсказок, упрощений и т. д.), необходимость в noscript-версии приложения в 2019…
Исходный код, примерная инструкция по установке и демо по ссылке (просьба вандалить тестировать в рамках УК РФ).

Постскриптум. Немного меркантильного в завершение. Подскажите с таким уровнем реально начать программировать за деньги? Если нет, на что обратить внимание в первую очередь, если да, подскажите где сейчас ищут интересную работу на схожем стеке. Спасибо.

Постпостскриптум. Ещё немного о деньгах и работе. Как вам такая идея: предположим человек готов работать над интересным ему проектом за любую з/п, однако данные о задачах и их оплате будут доступны публично (желательна доступность и кода для оценки качества исполнения), в случае если оплата будет существенно ниже рынка конкуренты работодателя могут предложить большие деньги за выполнение их задач, если выше — многие исполнители смогут предложить свои услуги по меньшей цене. Не будет ли такая схема в некоторых ситуациях более оптимально и справедливо балансировать рынок (IT)?