Еволюція CleverStyle Framework 6

Нещодавно вийшов перший реліз гілки 6.x, а це значить, що крім відкинутою зворотної сумісності є і нововведення, про які хотілося б розповісти.
Попередні зміни: частина 1, частина 2, частина 3, частина 4, частина 5.
Загалом кожен новий реліз спрощує сам фреймворк, другорядні можливості видаляються (їх можна реалізувати без втручання в ядро фреймворку), з'являються нові, а ті що залишилися поліруються.
Так само все більш важливим стає дати розробникам можливість відмовитися від вбудованої функціональності, яка може призводити до накладних витрат. Це дозволяє прискорити розробку за рахунок відповідної вбудованої функціональності, але в той же час не нести неминучих накладних витрат за те, що не використовується.

Ще більш легкий і швидкий фронтенд

Ще у версіях 5.x робота з многоязычностью інтерфейсу на фронтенде стала асинхронної. 6.x асинхронної стала завантаження перекладів, а так само підключення бібліотеки sprintf.js.
Загалом це означає дві речі:
  • кеш статики перестав бути залежним від мови, тобто при перемиканні мови інтерфейсу у вас інший файл завантажиться перекладів, але все інше викликається з пам'яті без змін
  • у випадку, якщо ви не використовуєте цей функціонал, ви не завантажуєте зайвого коду
Це значить, що якщо вам не потрібна підтримка веб-компонентів і ви не будете використовувати переклади на фронтенде — то оверхед фреймворку (на момент релізу) в продакшені:
  • 371 байт CSS (178 байт gzip)
  • 24846 байт JS (8371 байт gzip)
Це вже зовсім небагато (майже половину цього обсягу займає Alameda, сучасна версія RequireJS).
Але навіть це не межа, найближчим часом планую написати статтю про те, як влаштовано кешування статики у фреймворку, там буде інформація про те, як можна відмовитися від 100% фронтенда фреймворку в продакшені, як інтегрувати свою систему збірки при бажанні і так далі (поки що можна почитати нову сторінку документации).

Продуктивність фронтенда

На фронтенде покращена продуктивність роботи системних подій, і, що більш важливо, завантаження переказів.
Справа в тому, що переклади на фронтенде можуть бути використані або як рядки, або як методи. У другому випадку можна передати деякі аргументи і отримати відформатовану рядок з даними параметрами:
cs.Language('system_profile_').ready().then(function (L) {
console.log(L. hello('Guest')); // Привіт, Guest!
});

При цьому на кожен ключ в перекладах створювалося кілька нових функцій. Це не проблема, якщо ключів всього кілька, а от коли їх кілька сотень — це помітно.
В результаті рефакторінгу вдалося скоротити кількість створюваних функцій до однієї на ключ.
Так само покращена продуктивність деяких часто використовуваних користувальницьких елементів.
cs-icon
іноді має більше сотні екземплярів на сторінці, тому швидкість його роботи дуже важлива, в останніх версіях (починаючи з пізніх 5.x) він підтримує від 1 до 2 іконок (раніше можна було більше) і рендерить їх набагато швидше, уникаючи додавання/видалення елементів в своєму тіньовому дереві.

MySQL strict mode

MySQL переведений примусово в суворий режим. Це дозволяє уникнути ряд неприємних проблем, включаючи проблеми з безпекою.
В результаті включення суворого режиму було знайдено кілька мінорних проблем, тепер вони виправлені і покриті тестами.

XSS

Продовжуючи тему безпеки — реалізація функції
xap()
, яка використовується повсюдно для очищення вхідних даних, переписана і зараз базується на HTML Purifier. Тепер ця функція по справжньому безпечна, раніше вона такою, як виявилося, не була.

cs\CRUD_helpers

В багатомовних конфігураціях цей трейт не завжди правильно використав пошук. Пошук міг не враховувати багатомовні параметри при пошуку і сортування даних по власних полях таблиці, тепер же і власні поля та поля таблиць завжди коректно.
Так само пошук в багатомовною конфігурації тепер завжди використовує поточний мову системи, і не дозволяє вказувати його в якості параметра (інакше деколи виходили дивні не стикування, коли основна таблиця використовує одну мову, а пов'язана іншого).

Серверні оптимізації

Системні класи активно використовують трейты, але в деяких випадках завантаження трейтов може бути не дуже раціональною (наприклад, трейт, що займається побудовою кешу статики не потрібен при обробці API запитів).
Зараз ряд системних трейтов отрефакторены в самостійні класи, які завантажуються тільки коли дійсно потрібні.
Так само зроблено ряд дрібних оптимізацій, знайдених при профілюванні. Наприклад, на сервері істотний відсоток часу виконання займала завантаження перекладів з кеша (по суті, десериализация JSON), що не завжди використовувалося для API запитів і при вимкненому підтримки багатомовності. У подібних сценаріях завантаження перекладів більше не відбувається, вона відкладається до реального використання.
Тепер під звичайним Apache2 + PHP7 час рендеринга простий сторінки починається від 0.8 мс, тобто 0.0008, що раніше було можливе тільки під HHVM.

Видалена підтримка IE

Фреймворк більше не підтримує Internet Explorer, базова підтримка IE11 доступна в модулі Old IE, IE10 не підтримується зовсім ніяк.
наступної мажорній версії, швидше за все, IE11 теж буде відкинутий, і будуть підтримуватися 2 останні стабільні версії Edge, втім, те ж саме і з усіма іншими основними браузерами (іноді народ згадує про Safari 5 на Windows, але це більше не смішно).

Полірування внутрішніх інтерфейсів і структури

Продовжилася полірування внутрішнього API системних об'єктів.
Більше не потрібно використовувати додаткові методи для зберігання/отримання деяких полів конфігурації системи.
Самі ж підтримуваний поля тепер визначаються спеціальним класом
cs\Config\Options
(раніше бралися з JSON файлу), який крім назви поля і значення за замовчуванням повертає додаткові мета-дані, яких, в принципі, достатньо для автоматичної побудови UI, що в майбутніх версіях буде використано для повноцінного управління конфігурацією системи через CLI інтерфейс.
Виправлено порядок викликів методів ініціалізації і конструктора в
cs\Singleton
, що викликало деякі проблеми при роботі в режимі HTTP сервера.
Історично склалося використання
includes
перейменовано в
assets
(це спричинило за собою перейменування директорій по всьому проекту), що є набагато більш поширеним найменуванням.
На цій хвилі структура статики була перенесена з окремого файлу
includes/map.json
в ключ
assets
загального файлу з мета-даними модуля
meta.json
, де зберігається інформація з підтримуваними мовами, базах даних, залежності та інші деталі.
Ще одним великим перейменуванням стали движки. Движками називалися різні реалізації роботи з кешем, БД і сховищем, при цьому параметри підключення до БД можна було зустріти тип БД (
type
), а в сховищах зустрічалися такі собі з'єднання (
connection
).
Все це тепер консистентним іменується
drivers
/
driver
щоб не збивати нікого (в тому числі самого себе) з пантелику.

Видалення другорядних функцій

З ранніх alpha версій і до останнього релізу у фреймворку було два механізму блокувань користувачів:
  • тимчасове блокування користувача до певного моменту в майбутньому
  • тимчасове блокування IP користувача та після кількох невдалих спроб входу в систему
Обидві етих блокування були примітивними у другорядними, а тому видалені. Для другої блокування з'явилося кілька системних подій, які дозволяють повернути дану функціональність, і навіть більше, з допомогою сторонніх модулів.

Інші нові фічі

У модулі блогів додана підтримка SQLite в модулі блогів.
Поверх вже використовується
wp-cli/wp-cli-tools
пакету доданий патч, що реалізують HTML-подібний синтаксис для форматування відповідей у CLI інтерфейсі (оформлено у вигляді PR 100, але назработчики якось не поспішатимуть приймати патч, вирішив більше не чекати).
Патч дозволяє замість:
%gCleverStyle Framework%n version %y$version%n, CLI interface

Писати таке:
<g>CleverStyle Framework</g> version <b>$version</y>, CLI interface

Та навіть підтримуються вкладені теги, що без цього патча дуже боляче робити.
При використанні серверних підготовлених виразів тепер можна передавати більше параметрів, ніж потрібно, зайві будуть відкинуті. Іноді це буває зручно.
Додана підтримка template string з ES2015 в минификатор JS (якщо ви раптом таке використовуєте без конвертації в ES5).
Переклади вивантажені сервіс допомогою transifex, що має спростити переклад на інші мови, які я сам не знаю:)

Тестування і якість коду

Тестів стало набагато більше, вони набагато краще і покривають істотно більшу частину коду.
Всі системні класи покриті тестами, більшість на 100%, багато на 98-99%, зовсім деякі трохи менше.
Почалося покриття тестами контролерів — першими були покриті контролери, які відповідають за вхід/вихід користувача, зміну/відновлення пароля, зміна налаштувань профілю користувача.


Реальне покриття навіть більше, бо не тестується APC драйвер кеша (він проганяється в Travis CI, але локально у мене його немає), так само в деяких тестах складання пакетів і установки системи облік покриття тестами відключений через бага в Xdebug, але самі тести проганяються.
Істотно зросла якість коду за версією Scrutinizer (тут враховується не тільки код ядра, але і всіх модулів, що в репозиторії), на око майже 75% коду має оцінку A/B і немає коду з оцінкою F:


Наостанок

Завжди радий новим ідеям і конструктивним коментарям.
» Репозиторій на GitHub
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.