(Архив) Вышла первая версия фреймворка Matreshka.js

[getId]

Ура! Ещё один js framework.

Та самая картинка

[yurash]

На сайте используется CSS фреймворк Matreialize

хоть и опечатка, но забавно получилось. Раз Matreshka, значит нужен не materialize а matreialize

[xxxTy3uKxxx]

Заголовки для TypeScript есть в планах?

[Finom]

Пока нет, но Матрешка всегда открыта для пулл-риквестов.

[xxxTy3uKxxx]

Отлично, есть чем себя занять. Спасибо за хороший фреймворк

[lega]

В одном из предыдущих постов спрашивал и не получил ответа — есть ли возможность работать со вложенными объектами, например:

var app = new Matreshka;
app.bindNode( 'user.name', '.my-input' );
app.user = {name: 'Matreshka'};
app.user = {name: 'User'};

Не могли бы вы добавить Matreshka.js в «местный» бенчмарк.

[Finom]

Я бы лучше создал новый объект:

var app = new Matreshka;
app.user = new Matreshka;
app.user.bindNode( 'name', '.my-input' );
app.user.name = 'Matreshka';
app.user.name = 'User';

Вопрос по вашему бенчмарку добавил в список дел.

У меня есть другой бенчмарк коллекций

Вставка 10 элементов

Результат не самый лучший. Матрешка обгоняет Реакт только в ИЕ.

Вставка 100 элементов

Матрешка либо обгоняет либо стоит на ровне с другими фреймворками, кроме Ember. Странно, что самый быстрый (по слухам) React отстает местами от Angular.

Вставка 1000 элементов

Все фреймворки позади (они даже не видны на графике из-за значений < 1 операций в секунду), кроме Ember. React еще больше удивил.

Вывод можно сделать такой: при небольшом количестве элементов Матрешка немного отстает от других фреймворков но разница в скорости, как правило, не заметна при таком объеме данных. Начиная со ста элементов, Матрешка часто быстрее Реакта, «самого быстрого фрефмворка».

Интересно, что, Матрешка выигрывает у всех в IE (извините, так получилось). Ember оказался самым быстрым из этого списка почти при любом раскладе.

[lega]

У меня есть другой бенчмарк коллекций

Я уже комментировал этот тест на тостере, в нем много ошибок например для Ангуляра в такой ситуации нужно использовать track by иначе происходит построение нового DOM вместо его дополнения.
Knockout.js нужно тестировать асинхронно, т.к. у него рендер идет через setTimeout.
Ember не может быть самым быстрым т.к. он перерисовывает весь DOM, когда другие делают это «точечно».
Все тесты влияют друг на друга, т.к. при запуске перед ними разное кол-во DOM. Тесты провоцируют разный рендеринг — где-то есть перенос, где-то нет, какие-то тесты «двигают» всю страницу — это бъет по производительности.

самый быстрый (по слухам) React

Он не самый быстрый, если перефразировать слова его разработчиков — React быстрее чем Ангуляр если тест для Ангуляра сделать не правильно.

[Finom]

Если нужно использовать объект, то у Матрешки есть метод set (он может принимать объект).

var app = new Matreshka;
app.user = new Matreshka;
app.user.bindNode( 'name', '.my-input' );
app.user.set({name: 'Matreshka'});
app.user.set({name: 'User'});

[lega]

Я просто хочу найти эквивалентный код, в ангуляре мне через ajax прилетают данные, я их просто помещаю в модель — все работает, например такой код:
Полученный JSON:

{
  "user": {
    "name": "User",
    "address": {
      "city": "Moscow"
    }
  }
},

Получаем данные и помещаем в scope.

$.get('getUser', function(data) {
  scope.user = data.user;
  // call "digest" scope.$apply / scope.$scan
})

И на например «прибиндино» 2 поля:

<div>{{user.name}} <br/> {{user.address.city}}</div>

Я так понял что матрешка не рассчитана на работу с «иерархическими данными» (речь про данные, не про рендеринг), и в данном случае нужно за ранее создавать все возможные объекты, делать к ним биндинг, а для присвоения нужен врапер который будет копировать все значения.
Хотя можно перенести все значения в один объект (в «корень»), но все равно это заставляет меня перемещать данные туда-обратно.

[Finom]

Понял проблему. Как раз недавно возникла идея статичного метода toMatreshka (или просто to), которая конвертирует объект и его внутренности в экземпляры Матрешки. А для расширения такого объекта можно было бы воспользоваться аналогом merge из underscore.

Установим дефольные значения объекту

var app = MK.to({
	user: {
		name: '',
		address: {
			city: ''
		}
	}
});


app.user.address.bindNode( 'city', 'input' );

ajax( function( data ) {
	app.merge( data );
});

Как идея?

Но подход вызывает вопросы:
— Eсли внутри объекта содержится массив, заменять все элементы или добавлять?
— Если в дереве объекта найден необъявленный ранее объект, конвертировать ли его в Матрешку или оставить обычным объектом?

В общем, нужно подумать. Спасибо за то, что прояснили ситуацию. Такой возможности действительно сейчас нет.

[palkan]

В TodoMVC баг, однако: добавил два пункта, затем на одном кликнул на крестик – пишет, что «1 items left», а показывает два (Chrome, MacOS).

[Finom]

Уже исправлено. Баг был связан с небольшим упущением при большом рефакторинге Matreshka.Array.

[palkan]

А может стоит покрыть код тестами, а уже потом выпускать версию 1.0?

Вот все круто, но глупый баг в демо приложении и отсутстие тестов – это повод перестать рассматривать Матрешку для production целей.

[Finom]

Автоматическое тестирование, конечно, будет. Но, в целом, Матрешка достаточно стабильна, а фичи обкатываются в продакшне по несколько месяцев перед выходом релиза. Спешка с рефакторингом — результат спешки со статьями, дабы удовлетворить условия оферты Хабра по блогу компании. Прошу прощения за неприятное недоразумение.

[StreetStrider]

Две вещи вызывают некоторое опасание:
1. Использование собственных коллекций. Я понимаю, это нужно для более прямолинейной реализации биндинга через аксессоры, но множество других библиотек подобного типа умудряются делать такие вещи подкапотно (дельты / dirty-checking), так что модели пользователя (программиста) не трогаются. Я лично считаю, что очень важно уровень данных оставлять максимально независимым от библиотек. Это намного более лучшая интеграция и меньше отторжения у пользователя. Мне лично не нравится, что каждая либа считает вправе указывать мне какие модели использовать и как строить архитектуру.
2. Вызывает опасение этот код: this.on( 'change:x', function() {, а именно строковой литерал. Каждый раз, как архитектура становится достаточно сложной, приходится конструировать эти строки, соединять все эти change/пространства имён/идентификаторы и тому подобное. Строковой литерал должен быть строковым литералом и лучше в строках важные детали архитектуры не хранить. То есть здесь явно две сущности: change — имя события, x — конкретное имя биндинга. Минимальное что можно сделать, это разбить их на два аргумента, тем более, я уверен, под капотом это всё равно делается.

Да, не считайте это негативной критикой. Это просто мнение. Проект интересный, развивайте его дальше и желаю вам успехов.

[lega]

1. Использование собственных коллекций

Не только коллекций, но и объектов, нельзя просто взять и «положить» «json объект», нужно все данные оборачивать в «обертки», хотя автор упомянул что подумает над решением.

Я лично считаю, что очень важно уровень данных оставлять максимально независимым от библиотек.

Поддерживаю, а то уже есть фреймворки у которых не только данные «в обертках», но «свой» DOM, свой ajax, свой сборщик и т.д.

[Finom]

множество других библиотек подобного типа умудряются делать такие вещи подкапотно

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