Комментарии 4
Еще при утечках памяти в SPA можно завести счетчик переходов по роутам и на каждые X переходов делать принудительный reload страницы (сам не ангуляровец, бегло посмотрел документацию — должно подойти событие $locationChangeStart).
При активном использовании local storage и query string это позволит не терять состояние.
А тем временем можно постепенно отлавливать свои утечки и дожидаться фиксов в сторонних библиотеках, постепенно увеличивая это число.
Звучит диковато, но в реальных условиях такой подход может сэкономить нервы и пользователям, и разработчикам.
При активном использовании local storage и query string это позволит не терять состояние.
А тем временем можно постепенно отлавливать свои утечки и дожидаться фиксов в сторонних библиотеках, постепенно увеличивая это число.
Звучит диковато, но в реальных условиях такой подход может сэкономить нервы и пользователям, и разработчикам.
Почему-то такое решение в голову не приходило. Действительно, диковато, но очень хитро :)
В действительности, это не единственная проблема, которую мы решали. Длительная загрузка всего приложения по внутренней ссылке также актуальна, ведь каждая секунда ожидания в работе накапливается в часы, да и нервы пользователя желательно экономить.
В действительности, это не единственная проблема, которую мы решали. Длительная загрузка всего приложения по внутренней ссылке также актуальна, ведь каждая секунда ожидания в работе накапливается в часы, да и нервы пользователя желательно экономить.
Посмотрите, пожалуйста, в качестве SPA фреймворка basis.js, который создан для разработки приложений, использующих на стороне клиента большие объёмы данных.
Очень интересно ваше мнение о нём, в частности.
Не допускаете ли вы, что причиной низкой производительности может быть попытка использования модели MVC в вебе? Я не раз сталкивался с объяснениями того, почему это не эффективно.
Очень интересно ваше мнение о нём, в частности.
Не допускаете ли вы, что причиной низкой производительности может быть попытка использования модели MVC в вебе? Я не раз сталкивался с объяснениями того, почему это не эффективно.
Смотрел basis.js, по пока получил только поверхностное представление о нём, и в целом понравилось. По душе пришёлся подход к связыванию, что можно получать только значения, определённые для шаблона. Это позволяет защититься от хардкодинга, и писать сразу правильно. Собираюсь уделить этому фреймворку больше внимания, как появится время.
Вообще, в последнее время достаточно пристально следим за появлением и развитием клиентских фреймворков и подходов, так как ограничиваться только одним AngularJS не целесообразно, к тому же он подходит далеко не для всех задач (один из таких примеров как раз рассматривается в статье).
Интерес представляют возможности использования серверной генерации шаблонов (в нашем случае, Razor), вместо написание статических декларативных HTML-шаблонов, потому что при большом количестве моделей очень утомительно дублировать классы из C# в JavaScript — это здорово усложняет процесс разработки и особенно сопровождения. Модели в C# строго типизированные и несут «на себе» очень много мета-информации, достаточной как для генерации правильной UI-разметки, так и для валидации. Используя AngularJS нам пришлось об этом забыть :(
На данный момент, я пока убеждён, что причиной низкой производительности является не использование той или иной модели, а то, что мы пытаемся игнорировать тот факт, что веб-страница это всё таки веб-страница, а веб — это веб, и не стоит пренебрегать теми преимуществами, что это даёт, даже разрабатывая приложение.
Для работы с большим объёмом данных очень привлекательным нахожу технологию OData, но пока широкой поддержки её со стороны клиентских фреймворков к сожалению не наблюдается.
Вообще, в последнее время достаточно пристально следим за появлением и развитием клиентских фреймворков и подходов, так как ограничиваться только одним AngularJS не целесообразно, к тому же он подходит далеко не для всех задач (один из таких примеров как раз рассматривается в статье).
Интерес представляют возможности использования серверной генерации шаблонов (в нашем случае, Razor), вместо написание статических декларативных HTML-шаблонов, потому что при большом количестве моделей очень утомительно дублировать классы из C# в JavaScript — это здорово усложняет процесс разработки и особенно сопровождения. Модели в C# строго типизированные и несут «на себе» очень много мета-информации, достаточной как для генерации правильной UI-разметки, так и для валидации. Используя AngularJS нам пришлось об этом забыть :(
На данный момент, я пока убеждён, что причиной низкой производительности является не использование той или иной модели, а то, что мы пытаемся игнорировать тот факт, что веб-страница это всё таки веб-страница, а веб — это веб, и не стоит пренебрегать теми преимуществами, что это даёт, даже разрабатывая приложение.
Для работы с большим объёмом данных очень привлекательным нахожу технологию OData, но пока широкой поддержки её со стороны клиентских фреймворков к сожалению не наблюдается.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
SPA-архитектура для CRM-систем: часть 2