Зачем писать свой React Data Grid в 2019

Хочется сказать отдельное спасибо за статью от команды DevExtreme. Такой фидбек о реальном использовании наших продуктов крайне ценен. Многие упомянутые проблемы мы сами видим, разделяем и планомерно устраняем. Совсем недавно мы добавили возможность использовать виртуальный скроллинг с ленивой загрузкой данных с сервера в нативный DevExtreme React Grid.

Также теперь мы даем из коробки React обертку для DevExtreme JavaScript DataGrid. В некоторых сценариях, трудности с управлением внутренним состоянием компонента действительно есть, работаем над этим :)

HTML5 в мобильной разработке — что выбрать?

К сожалению, главное не это, главное когда будет написано конечное приложение в соответствии с требованиями и будет летать также как и спайк созданный на коленке за полчаса. По опыту было много случаев когда команда с горящими глазами после реализации такого спайка допиливала его до real-life приложения и все становилось уже не так радужно как до этого. Хочется пожелать вам успехов в этом нелегком деле и, конечно, попробовать что-нибудь готовое на ощупь :)

HTML5 в мобильной разработке — что выбрать?

Все же считаю что WebWorkers не заслуживают такого внимания, которое мы им здесь уделяем, думаю это вопрос времени, учитывая популярность, которую набирает Android. Ваши 90% я бы еще умножил на процент пересечения рынков вашей компании и целевого рынка PhoneJS, к сожалению сложно сказать насколько сильно они пересекаются. Эта информация была бы действительно ценной. Т.к. пока не понятно почему же эти 90% не хотят стандартный интерфейс и готовы платить за это (перекрасить кнопки в зеленый цвет — не считается). Ваш доклад с удовольствием бы послушал, спасибо за приглашение. Ну и если у вас действительно есть какие-то революционные наработки в области мобильной веб-разработки, ждем реализации PropertyCross.

HTML5 в мобильной разработке — что выбрать?

1) на андроиде нет WebWorkers, поэтому о каком их использовании может идти речь?

Если Вы что-то слышали о graceful degradation и progressive enhancement, то Вам должно быть очевидно, что глупо отказываться от использования какой-то фичи, только из-за того что ее не поддерживает какая-то часть целевых устройств. Нет поддержки WebWorkers — сменим стратегию на однопоточное вычисление. Но там где они поддерживаются приложение станет более отзывчивым. Более того, я уверен, что в последующих версиях андроида WebWorkers станут доступны, или встроенный браузер вовсе заменят на Chrome.

когда перобретаю смартфон я догадываюсь что он будет медленее моего десктопа или ноута.

Суть статьи по приведенной ссылке не в том чтобы сказать что мобильник медленнее десктопа, а в том чтобы сравнить по производительности web/native, причем не только в терминах быстрее/медленнее, но и в конкретных цифрах. Уверен, многие нашли эту информацию полезной.

«Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера.» извините, но это не самое необходимое. Как раз наоборот: более чем в 90% случаев — заказчик хочет нестандартный UI(поверьте, наша компания имеет опыт в разработке более чем 150 мобильных приложений, из них только 4 для собственного бренда), и что потом делать?

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

Во-вторых, я знаю много компаний, где заказчик хочет нестандартный UI в 100% случаев, это компании, которые занимаются разработкой игр. Но даже этот факт не дает мне права утверждать, что все фреймворки, которые помогают нарисовать стандартный UI бесполезны. И это совершенно не зависит от количества мобильных приложений, которые эти компании разработали.

В-третьих, не нужно путать понятия «позволяет» и «обязывает». PhoneJS позволяет не задумываться об отрисовке UI, если в этом нет необходимости, но в то же время он позволяет откастомизировать UI в соответствии с требованиями, если это необходимо. Хоть с нуля можно наверстать.

В качестве затравки видео на програму которая делает абсолютную хрень.

Без комментариев.

Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.

Вот с этим сложно не согласиться.

HTML5 в мобильной разработке — что выбрать?

Для роутинга можно найти множество бесплатных JavaScript библиотек. API для геолокации доступно в большинстве современных браузеров. Если нужно больше, то можно воспользоваться PhoneGap API. Для упаковки в нативный контейнер, можно использовать PhoneGap build. Если не хочется самому реализовывать транзишны между вьюшками и другие аспекты SPA, то можно взять тот же PhoneJS, которому посвящена эта статья и отказаться от использование встроенных виджетов и лейаутов, сверстав UI самому, тем более если Вы это прекрасно умеете делать, а фреймворк позволяет. Разве что заплатить за виджеты все равно придется (если планируется коммерческое использование), т.к. они не поставляются отдельно.

HTML5 в мобильной разработке — что выбрать?

Все зависит от того, что конкретно Вам нужно от фреймворка. Если нейтральный UI, можно посмотреть на twitter bootstrap или jQueryMobile, где можно воспользоваться конструктором тем. А так, конечно, все познается в сравнении :)

HTML5 в мобильной разработке — что выбрать?

Автор пытается подтвердить гипотезу о том, что существуют такие типы приложений, для которых желаемый результат можно получить с использованием HTML5, затратив при этом гораздо меньше ресурсов чем с использованием нативной разработки. Другими словами, типы приложений, для разработки которых HTML5 более эффективен. И здесь речь идет не о том, когда человек выбирает одно из десятка приложений опубликованных в аппсторе, и может безболезненно снести одно и поставить другое, а о том когда ему приходится выбирать между «объехать все точки в городе, записать на бумажку и вечером перенести все в базу данных вручную» и «воспользоваться мобильным приложением, которое местами притормаживает и провести 2 оставшихся вечером часа за кружечкой пива или в кругу семьи». Для меня выбор был бы очевиден. Минус здесь в том, что приложений подобного типа нет в списке демок продукта.

PhoneJS — Новый HTML5-фреймворк для мобильных приложений

Извиняюсь, похоже ошибся веткой. Это ответ на этот комментарий.

PhoneJS — Новый HTML5-фреймворк для мобильных приложений

Жалко Вы не упомянули конкретные демки, т.к. в идеале, конечно, сравнивать лучше на одном и том же приложении, которое написано на различных фреймворках. В этом плане официальные демки KendoUI минималистичны и заточены именно под перформанс, что с точки зрения продаж, более правильно. Люди обычно выбирают такого рода продукты именно исходя из производительности. Но это чревато разочарованием на последующих стадиях разработки, когда скоро выпускать продукт, а оказывается, что все тормозит. Мы же попытались сделать наши демки реальными приложениями, которые будут писать люди и которыми уже можно пользоваться (за исключением Kitchen Sink) и оценить реальную производительность. Ну и как уже было неоднократно сказано, мы уже знаем некоторые наши узкие места и сейчас работаем над их устранением, и некоторые из них постараемся включить в ближайшие миноры. В любом случае, спасибо за отзыв.

Вертикальный скроллинг содержимого страницы в стиле Mac OS X Lion

Пытались заюзать его в нашем проекте, под WP7 не работает совсем.

Кодоребус или паттерн «стратегия» на .Net 4.0

Как я уже сказал выше — выражение верно синтаксически и скомпилируется если это декларация поля класса, а не локальной переменной.

Кодоребус или паттерн «стратегия» на .Net 4.0

Т.е. Вы меня пытались убедить что мой пример абсолютно нерабочий, не смотря на то, что этот код безотказно работает уже долгое время, а мои доводы что «it depends» были названы невежеством и попыткой оправдать быдлокод. А теперь на попытку привести хоть какое-то более общее рабочее решение, Вы говорите что его не существует.

Кодоребус или паттерн «стратегия» на .Net 4.0

Ну и раз уж пошла такая пьянка, давайте улучшим статью вместе и напишем правильную асинхронную стратегию, предлагаю начать, например, с такого варианта:

    public class AsyncStrategy {
        public void DoWork(Action work) {
            BackgroundWorker worker = new BackgroundWorker();
            worker.DoWork += (s, e) => { work(); };
            worker.RunWorkerCompleted += worker_RunWorkerCompleted;
            worker.RunWorkerAsync();
        }
        private void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) {
            if(e.Error != null) {
                //handle error here
            }
            BackgroundWorker worker = (BackgroundWorker)sender;
            worker.RunWorkerCompleted -= worker_RunWorkerCompleted;
        }
    }

Использование:

            MyWorker worker = new MyWorker();
            AsyncStrategy asyncStrategy = new AsyncStrategy();
            worker.SetDoWorkStrategy(asyncStrategy.DoWork);

Кодоребус или паттерн «стратегия» на .Net 4.0

Для тех, кто счел данный топик рекомендацией для реализации асинхронности. НИКОГДА не пишите так

(Action work) => { Task.Factory.StartNew(work); }

если не понимаете какими проблемами это может обернуться.

А пример давайте заменим на логирующую стратегию:

(Action work) => {
  Log("Task started");
  work(); 
  Log("Task completed");
}

Кодоребус или паттерн «стратегия» на .Net 4.0

> this.action = action => action();

Это не объявление поля, а его инициализация, я имел ввиду такой код:

    public class MyClass {
        Action<Action> action = (Action action) => { action(); };
        ...

Он скомпилируется без проблем.

И где здесь вы хотите использовать BackgroundWorker?

   Action<Action> action = (Action action) => { action(); };

И видимо придется третий раз повториться что реализовать асинхронную стратегию каждый может так как ему нравится и как походит для решения его конкретных задач, в соответствии с его принципами и опытом разработки. Представленная статья это не best parctices по реализации асинхронности, а об одном из множества способов изменения поведения класса, который не требует добавления новых сущностей.

Кодоребус или паттерн «стратегия» на .Net 4.0

Я новичок на хабре, а опыт он приходит с годами. Не думал что каждый байт демонстрируемого здесь кода воспринимается читателями как рекомендация к его использованию в неизменном виде. Мне казалось что каждый его профильтрует и возьмет для себя то что посчитает нужным. В следующий раз буду более осмотрителен при выборе примеров.

Кодоребус или паттерн «стратегия» на .Net 4.0

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

А сколько бы денег дали? Ну так, ради интереса :)

Кодоребус или паттерн «стратегия» на .Net 4.0

Все верно, поэтому тесты на асинхронное выполнение не должны полагаться «авось успеет», в этом случае должна быть четкая синхронизация потоков.

Кодоребус или паттерн «стратегия» на .Net 4.0

> •Верен ли он синтаксически? Скомпилируется ли он?
> Нет, переменная с именем «action» не может быть объявлена в параметрах лямбды/делегата, так как переменная с таким именем уже объявлена.

А если этот объявление поля класса, а не локальной переменной?

> •Как можно улучшить этот код? (Как бы его написали Вы?)
> В C# есть события. Я бы сделал событие с внятным именем.

А могли бы сюда примерчик запостить?

Кодоребус или паттерн «стратегия» на .Net 4.0

Такие тесты есть.