Как мы создавали свой Framework и почему?

Константин Кривленя

Компания Taucraft

Почему мы решили написать свой framework.

Пролог.

Поиск альтернатив в начале 2011 года.

Вывод

Что мы хотели от framework-а.

Что же нужно для счастья от современного framework-а.

  1. Слабосвязанная архитектура -> Масштабируемость;

Архитектура framework

  1. Событийно-ориентированная модель;

Преимущества событийно-ориентированной модели.

  1. Слабая связанность компонентов и его частей. Любая функциональность может быть использована неоднократно, легко отключена или подключена;

Схема связей компонентов

structure

Чуть-чуть про реализацию

  1. AMD - require;

Проблемы framework-a, основанного на модели событий, и как мы с ними боремся.

Часто необходимо было реагировать на склейку нескольких событий. Приходилось писать код вроде ниже приведенного:
            bus.on('afterRender',function(event,$element){
             bus.on('settingsChanged',function(event,settings){
             /**Какой-то код**/
             })
            })
        

Что делать?

Пишем свой язык описания склейки событий.

Возможности языка

Простой способ подписки на события. Описываем функции как property объекта:
                    "bus afterRender":function(evt,data) {
                     /**реагируем на события после рендера шаблона**/
                    }
                

Возможности языка

Склеиваем события, произошедшие однократно:
                    "bus afterRender + settingsChanged":function(evt,
                            $element,    settings) {
                        /**реагируем на события рендера шаблона и изменения настроек**/
                    }
                

Возможности языка

Используем данные события, произошедшего однократно с повторяющимся событием.
                    "bus afterRender:last + settingsChanged":function(evt,
                            $element,    settings) {
                       /**реагируем на события рендера шаблона(данные с последнего проброшеного
                        события)и изменения настроек**/
                    }
                

Возможности языка

Используем порядок возникновения событий.
                    "bus settingsChanged > afterRender":function(evt) {
                       /**реагируем на события рендера шаблона и изменения настроек,учитывая порядок возникновения**/
                    }
                

Возможности языка

А можно три события склеить? Да можно. Даже так:
                    "bus settingsChanged + ... +n":function(evt,data,..,nData) {
                       /**Данные получаем в аргументах**/
                    }
                

Еще проблемы? Да, гибкость.

Каждый extension может как генерировать события, так и реагировать на них. Поэтому мы ввели соглашение - "события для других extensions может генерировать либо main extension, либо model extension". В дополнительных extensions создаем точки входа, которые необходимы для его работы.

Profit?

  1. Получили framework, который решает наши проблемы.

Вопросы?

Контакты

Twitter
Github
Хабр