Комментарии 30
Совсем не в тему, но у вас очень красивое и удобное приложение под iOS, только за одни титры под видео, с перекладом по словах, можно отдать ему сердце :)
ждет в свои ряды разработчиков
Хантим-увольняем. Отличная стратегия же.
Добавьте пожалуйста в интерфейс под iOS класс .noselect (это ведь webapp?) чтобы постоянно не выделялся текст при использовании.
.noselect {
-webkit-touch-callout: none;
-webkit-user-select: none;
user-select: none;
}
.noselect {
-webkit-touch-callout: none;
-webkit-user-select: none;
user-select: none;
}
До сих пор не синхронизируются данные для тренировок под android.Я уже эту тему поднимал месяца 3-4 назад. Так и не исправлено.
На сайте, к примеру, доступно для тренировок 1500, а на телефоне 800.
На сайте, к примеру, доступно для тренировок 1500, а на телефоне 800.
Плюс: будет ли возможно отмены изучения материала выбранного на тренировках. Бывает, случайно не тот выберешь, и чтобы он не висел в списках приходиться подтверждать «я понял текст».
Спасибо за статью. Могли бы вы раскрыть подробнее, чем вам не подошла архитектура Flux, и какие плюсы вы получили от Redux?
Flow какой-то слишком аморфный: такое впечатление, что многие детали реализации ребята из фейсбука решили отдать на откуп сторонним разработчикам, а про некоторые и вообще забыли (например, асинхронные операции).
Так же не очень было непонятно, зачем необходимо несколько сторов, которое само по себе вводит дополнительные сущности вроде dispatcher'а и функции waitFor.
На самом деле мы его попробовали и получилось как-то… Не очень. Чисто по ощущениям.
Redux отличился более продуманной архитектурой и более внятной документацией.
Очень подкупала его идея декларативности action-ов, хотя в примере с async actions автор почему-то от неё отходит. Самое забавное то, что понимаешь, как можно сделать то же самое подекларативней, за счёт middlewares.
Ну и data-flow как-то в redux более ясный: Есть стор (один, единственный), единственная цель которого — хранить текущее состояние и уведомлять о его изменениях и reducer, единственная цель которого — возвращать новое состояние исходя из переданных ему состояния и action-а.
Возможно, flow тоже подразумевал под собой эти идеи, но в redux они более выражены и лажат на поверхности =)
Так же не очень было непонятно, зачем необходимо несколько сторов, которое само по себе вводит дополнительные сущности вроде dispatcher'а и функции waitFor.
На самом деле мы его попробовали и получилось как-то… Не очень. Чисто по ощущениям.
Redux отличился более продуманной архитектурой и более внятной документацией.
Очень подкупала его идея декларативности action-ов, хотя в примере с async actions автор почему-то от неё отходит. Самое забавное то, что понимаешь, как можно сделать то же самое подекларативней, за счёт middlewares.
Ну и data-flow как-то в redux более ясный: Есть стор (один, единственный), единственная цель которого — хранить текущее состояние и уведомлять о его изменениях и reducer, единственная цель которого — возвращать новое состояние исходя из переданных ему состояния и action-а.
Возможно, flow тоже подразумевал под собой эти идеи, но в redux они более выражены и лажат на поверхности =)
Достаточно сумбурно, но в целом познавательно. Совсем недавно на highload 2015 был отличный доклад на аналогичную тему перевода старого фронтенда на новый лад в Акронис. Так вот ребята не испугались и таки провели постепенный переход с ExtJS на React + собственную реализацию Flux. Соответственно встает несколько вопросов:
1) Что же у вас за такой магический сборщик, в который и JSX не вставляется, и ES6 не подтягивается, но выкинуть на свалку его вы не захотели? И вместо того, чтобы взять готовые webpack + babel, вы решили написать свою обвязку к virtual dom? На мой взгляд, если не начать переводить код на ES6 сейчас, то через год-два фронтендеры будут задавать вам на собеседованиях дополнительные вопросы типо: «IE6 вы тоже еще поддерживаете да?».
2) Самому очень нравится Redux + чистые функции. Но используете ли вы какую-то библиотеку для immutable данных или свое решение?
1) Что же у вас за такой магический сборщик, в который и JSX не вставляется, и ES6 не подтягивается, но выкинуть на свалку его вы не захотели? И вместо того, чтобы взять готовые webpack + babel, вы решили написать свою обвязку к virtual dom? На мой взгляд, если не начать переводить код на ES6 сейчас, то через год-два фронтендеры будут задавать вам на собеседованиях дополнительные вопросы типо: «IE6 вы тоже еще поддерживаете да?».
2) Самому очень нравится Redux + чистые функции. Но используете ли вы какую-то библиотеку для immutable данных или свое решение?
Достаточно сумбурно
Ровно настолько, насколько остуществлялся и сам переход :-)
Что же у вас за такой магический сборщик, в который и JSX не вставляется, и ES6 не подтягивается, но выкинуть на свалку его вы не захотели?
Почему же не захотели? Очень даже хотим заменить его на webpack (даже изучаем сейчас это дело), но это несколько сложней, да и нужно отвлекать на это дело бекендеров (чтобы встроить в текущую систему деплоя). А вот поиграться с реактом и прочими штуками руки чешутся, да и бекенд не требуется)) Но всё же мы планируем и сборщик нормальный и es6 (я так вообще мечтаю о TypeScript :-D), ну и пересесть с «велосипеда» на react. Но это всё упирается во время, да и про другие задачи нельзя забывать)
Подозреваю, что бекендеров вам особо отвлекать и не придется — настройка webpack лежит на ваших плечах, с их стороны нужно будет только прописать команду в скрипте сборки, если у вас туда нет доступа. Ну и поставить webpack на машине-сборщике.
Ну, почти) ведь надо ещё
— продумать конфигурацию для puppet, чтобы он установил nodejs, подтянул нужные либы
— понять, каким образом статика выливалась на cdn и либо как-то перенести такой же механизм в webpack, либо как-то переделать
ну и куча всяких незаметных по началу нюансов, которые всплывают в процессе)
— продумать конфигурацию для puppet, чтобы он установил nodejs, подтянул нужные либы
— понять, каким образом статика выливалась на cdn и либо как-то перенести такой же механизм в webpack, либо как-то переделать
ну и куча всяких незаметных по началу нюансов, которые всплывают в процессе)
Но используете ли вы какую-то библиотеку для immutable данных
Immutable данные пока не используем. Вообще, хотелось использовать Immutablejs, но либа показалась нам большеватой. А пока reducer всегда работает с deep-copy стейта, изменяя его по старинке. Уведомляем об изменениях стейта всегда, а не только когда реально произошли изменения… Пока вроде не сильно проседает в производительности, ну а как просядет — впору будет задуматься и об immutable структурах.
После прочтения показалось, что первым делом вам нужно избавиться от этого загадочного сборщика, который вставляет такие палки в колеса. Нашли время, готовы были перейти на bleeding edge — но в итоге из-за него написали свой велосипед (хоть и продуманный, хоть и react-подобный).
что у вас там за такой загадочный сборщик, которому сложно дописать поддержку того же бабеля?
Вам нужно пойти дальше: ClojureScript или Elm на худой конец
Вы WinPhone app совсем забросили, или как? Кстати, с какой-то версии стало дико неудобно в несколько кликов добавлять новое слово. Раньше можно было в один клик, а ещё оно тормозит сильно на Lumia 920, а это не самый слабый WinPhone.
Добавьте тайл для добавления слова на рабочий стол. Это самый быстрый и удобный способ (среди всех 3х платформ) для добавления слова или просмотра перевода, сам им пользуюсь. По факту, всё приложение не запускается, открывается только нужная часть. Тайл можно добавить с экрана добавления, ну или Лев его предложить должен.
А по поводу «не самый слабый WinPhone» — это вы MS расскажите; 1020 тормозит так, что некоторые приложения просто не хотят запускаться. Проблема в первую очередь аппаратная: приложения написанные под Windows Phone 8.1 работают на новом движке, который не оптимизирован под девайсы, изначально выпущенные с 8.0. Приложение Lingualeo реализованно как Universall App (тот, который для 8.1, где общее всё, кроме дизайна).
А по поводу «не самый слабый WinPhone» — это вы MS расскажите; 1020 тормозит так, что некоторые приложения просто не хотят запускаться. Проблема в первую очередь аппаратная: приложения написанные под Windows Phone 8.1 работают на новом движке, который не оптимизирован под девайсы, изначально выпущенные с 8.0. Приложение Lingualeo реализованно как Universall App (тот, который для 8.1, где общее всё, кроме дизайна).
Ух ты, за тайл огромное спасибо! Как-то не очевидно для меня это оказалось.
По поводу WinPhone, ну, не знаю, подавляющая часть приложений летает, вроде бы.
По поводу WinPhone, ну, не знаю, подавляющая часть приложений летает, вроде бы.
Про тайл в велкоме Лев говорит, возможно пропустили, или уже просто не нажимаете на Льва :)
А про винфон — тот же 6tag работает с перебоями. Т.е. если сравние работу приложений на *20 моделях и хотя бы на *30 (а ведь уже *50 выходят, но уже с Windows 10), то почуствуете разницу. Это примерно как сравнивать Lumia 800 и 820.
А про винфон — тот же 6tag работает с перебоями. Т.е. если сравние работу приложений на *20 моделях и хотя бы на *30 (а ведь уже *50 выходят, но уже с Windows 10), то почуствуете разницу. Это примерно как сравнивать Lumia 800 и 820.
Сколько у вас фронтендщиков? Все "универсальные" или делите на верстальщиков и JS-ников?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реакция на долголетие: как мы обновили фронтенд Lingualeo