zorro1211
0

Думаю не особо и просили, но раз надо, значит надо:


(async function () {
  for (let i of Array(100).keys()) {
    await new Promise(res => {setTimeout(res, 50)});
    const val = i + 1;
    const mod3 = val % 3;
    const mod5 = val % 5;
    let out = '';
    if (mod3 && mod5) out = i + 1;
    else {
      if (!mod3) {out += 'Miss';}
      if (!mod5) {out += 'Kiss';}
    }
    console.log(out);
  }
}())
zorro1211
0

Кстати да, разница в мелочах, нужно было быть внимательнее.
При делении на 15 у меня же выводит и Miss и Kiss? Или не нравится что в разных строчках?

zorro1211
–1

Менее 10 минут:


Array(30).fill().forEach((x, i) => {
const val = i + 1;
const log = val => setTimeout(() => {
  console.log(val);
}, i * 1000);
if (val % 3 == 0 && val % 5 == 0) {
  return log('FizzBuzz');
} else if (val % 3 == 0) {
  return log('Fizz');
} else if (val % 5 == 0) {
  return log('Buzz');
}
return log(val);
})

Ещё вот такого варианта не видел в ответах:


(async function () {
  for (let i of Array(100).keys()) {
    await new Promise(res => {setTimeout(res, 50)});
    const val = i + 1;
    const mod3 = val % 3;
    const mod5 = val % 5;
    if (mod3 && mod5) console.log(val);
    else {
      if (!mod3) {console.log('Miss');}
      if (!mod5) {console.log('Kiss');}
    }
    console.log('----');
  }
}())
zorro1211
0

Есть печенье для утоления печали https://github.com/felixrieseberg/windows-build-tools :)

zorro1211
0

Судя по видео ниже, в MobX изпользуют observables, но по коментариям от выступающей она зачислила его в OO мир а не в FP


MobX vs Redux: Comparing the Opposing Paradigms - React Conf 2017
zorro1211
0

Фанкторы (извиняюсь за произношениe) или композиция для улучшения читаемости кода:


//italian-pasta style

function updateUrl(url) {
  return addParam(
    addParam(
      removeParam(
        updateParam(url, 'x', 1),
        'y'
      ),
      'z', 2
    ),
    'hello', 'world'
  );
}

//vs multiple re-assignments

function updateUrl(url) {
  url = updateParam(url, 'x', 1);
  url = removeParam(url, 'y');
  url = addParam(url, 'z', 2);
  url = addParam(url, 'hello', 'world');
  return url;
}

//vs Functor

function updateUrl(url) {
  return [url]
    .map(x => updateParam(x, 'x', 1))
    .map(x => removeParam(x, 'y'))
    .map(x => addParam(x, 'z', 2))
    .map(x => addParam(x, 'hello', 'world'))
    .reduce(x => x);
}

//vs Functor with curried functions

function updateUrl(url) {
  return [url]
    .map(updateParam('x', 1))
    .map(removeParam('y'))
    .map(addParam('z', 2))
    .map(addParam('hello', 'world'))
    .reduce(x => x);
}

//vs composition with curried functions

const updateUrl = compose(
  addParam('hello', 'world'),
  addParam('z', 2),
  removeParam('y'),
  updateParam('x', 1)
);
zorro1211
+1

Для себя пока решил использовать напрямую классы с PureComponent, вместо обертки — не нужно конвертировать если нужны life-cycle методы, мой редактор (WebStorm) хорошо работает с классами (auto-complete), но не с функциональными компонентами. Хотя конечно синтаксис раздут по сравнению с фунциональными компонентами, что можно вылечить снипетами, но лучше я дождусь оптимизаций со стороны реакта.

zorro1211
0

Вопрос от новичка — почему нельзя заменить объект внутри массива на новый? Могу предположить что могут быть проблемы с time travel, но точно объяснить что в таком случае сломается не могу. Спасибо.

zorro1211
0

Спасибо за перевод.


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


Быстрый поиск нашел eslint плагин, заточенный под delegated-events библиотеку и он предупреждает об использовании input, keydown, keypress, keyup, mouseout, mouseover, mousemove, scroll для document. Думаю можно взять его за основу чтобы сделать плагины под другие библиотеки.


Насчет react, вот пример в обход проблемы.

zorro1211
+1
zorro1211
0

Ура, нашелся оптимистично настроенный человек наконец-то =) Спасибо, подняли настроение.

zorro1211
+1

Согласен. Насчет примера выше, имеет ли смысл каждый раз создавать объект? Mожет лучше сразу:


const obj2 = keys.reduce((o, key) => 
  Object.assign(o, { [key]: key }), {});
zorro1211
+1

Копирование объектов может быть быстрее: https://habrahabr.ru/post/283090/

zorro1211
+1

Насчет клонирования можно (и скорее всего нужно) применить оптимизацию: https://habrahabr.ru/post/283090/. Про freeze лучше забыть, слишком медленно.

zorro1211
+2
ЗЫ. кто дойдёт до 20 уровня?


Остановился на 108. Хорошо бы добавить концовку =)

zorro1211
+1

Очень понравилось ваше вступление про Джона, перевел для коллег =)


Перевод

A bad programmer John made a mistake in the code, due to which every user of the program was forced to spend an average of 15 minutes to find a work around the problem. There were 10 million members. In total they wasted 150 million minutes = 2.5 million hours. If a person sleeps 8 hours a day, then 16 hours are left for the conscious activity. That is, John has destroyed 156,250 man-days ≈ 427.8 person-years. The average man lives 64 years, so John had killed as many as 6.68 people.


Are you sleeping well, John — serial programmer?

zorro1211
0

Можно, все работает.

zorro1211
0

Добавлю про преимущества flow. На этом слайде демонстрируется один из наглядных примеров, хоть и надуманный немного. Так же babel может убирать типы из кода чтобы затем трасформировать надстройки вроде object spread или другие новшества которые могут появиться в языке. Если нужно использовать что-то вроде https://github.com/lodash/babel-plugin-lodash то придется компилировать 2 раза. Из минусов большая задержка была с поддержкой windows.


Но это не умоляет достоинств typescript. Он тоже очень хорош.

zorro1211
0

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

zorro1211
0

Уважаемый TheShock вам по-любому виднее! Я только разбираюсь c ФП и считаю что хорошо понимать где его нужно использовать, где не нужно. Тоже самое и с class, closure, и т.п. Особенно в свете последих статей от Eric Elliot, а также материалов от Brian Lonsdorf. Хотелось бы материалов без предпочтения сравнивающих разные подходы, рассматривая где и когда их использовать. Но раз такого нету, приходится через комментарии (ну и в личных проектах) вот так узнавать мнение =) Простите мне мое лукавство.


П.с. спасибо вам за ваши статьи и комментарии на хабре, всегда очень интересно вас читать!

zorro1211
0

Спасибо за ответ!


будет очень больно

Да, та же проблема что и у multiple inheritance. Хорошо что в js её не так сложно решить как в java, c#.

zorro1211
0
  1. Признаюсь тут я дилетант, но даже мои дилетантские тесты показывают что для большого количества объектов постоянное клонирование приводит к задержкам, так что я согласен. Интересно, есть ли материалы по решению этой проблемы для ФП...
  2. :) Не до такой степени pure конечно. Примерно как в Redux.
zorro1211
0

ФП тут не причем. Я говорю о прототипном программировании учитывая что прототип это объект и в js объекты динамически расширяемы. Посмотрите пожалуйста на мои ссылки ещё раз, особенно на первую. Как вы на одних лишь классах решите проблему из видео?

zorro1211
0
К чему мне ваши ссылки на ресурсы для джуниоров?

Вы забыли пару восклицательных знаков =)


Так и не поняли чем эти миксины могут навредить большому проекту?

Хотелось бы разобраться. Если вас не затруднит.

zorro1211
0

Здесь приведены примеры проблем которые решит webassembly: https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.9to9ao9py

zorro1211
0

У вас очень односторонний комментарий :)
https://youtu.be/n6MRsGwyMuQ?t=4m54s


Нужно понимать чем классы могут навредить: https://www.youtube.com/watch?v=wfMtDGfHWpA, http://martinfowler.com/bliki/CallSuper.html
И как с этим бороться: https://github.com/stampit-org/stampit, миксины

zorro1211
0

Спасибо за комментарий, я пытаюсь в этой теме разобраться и у меня есть небольшой фидбэк к вашему комментарию:


Но! Почему-то миллионы леменгов хотят принести ООП и систему классов

Да, это целая проблема. Потому что: https://www.youtube.com/watch?v=wfMtDGfHWpA
Ещё примеры: https://medium.com/javascript-scene/how-to-fix-the-es6-class-keyword-2d42bb3f4caf а так же многие другие статьи Eric Elliott
Один из вариантов решения (возможно не самый лучший, но не плохой так точно): https://github.com/stampit-org/stampit


jQuery чисто прототипная библиотека, хоть new и скрыт за фабричной функцией.
Backbone, верно, проблема разобрана здесь: https://vimeo.com/69255635
Lodash, с точки знения пользователя вообще функциональная библиотека.


Вот представим, что у нас есть Quake, написанный на js (Quake — это очень маленькое, по объемам логики, приложение). И у нас есть ошибка, конкретную точку, где она проявляется — мы знаем. Как найти все пути, которые приводят к этой точке кода?

Возможно FP может помочь? Например Redux с глобальным state и Immutable data может помочь отследить что привело к этой ошибке. Плюс в реальном времени её можно пофиксить. Поскольку весь код написан на pure functions, никаких посторонних эффектов быть не должно.

zorro1211
0

Показать не смогу, но был человек на интервью который хорошо знал api angular, но пройти хотя бы на 70% http://perfectionkills.com/javascript-quiz/ так и не смог.

zorro1211
0

Вот 2 теста замечательных на знание языка. Моя практика показывает что с ребятами которые хуже его проходят, сложнее работать и наоборот. Был один случай где человек хоть и не знал как конкретно язык работает, все равно не сдавался и выдавал предположения, которые были логичны и один из вариантов был верным. В данный момент он один из лучших разработчиков у нас.


  1. http://perfectionkills.com/javascript-quiz/
  2. http://perfectionkills.com/javascript-quiz-es6/
zorro1211
0
It's now enabled by default in Canary and you can't configure it anymore.

Можно уже через Canary пользоваться нормально. В Chrome тоже можно включить эту фичу, почитайте комменты в вашей ссылке.

zorro1211
0

На самом деле очень удобно для глаз ставить паттерны в фон, например пергамент + простая подсветка и будет казаться что читаешь книгу


zorro1211
0
Все верно. Спасибо за комментарий.
zorro1211
0
Мне кажется это дело привычки, можно без труда понять какой модификатор, где элемент — подход к именованию классов практически не изменился. Уверен что на практике найти блок будет совсем легко.
zorro1211
0
Привет, давай попробуем разобраться. Если в проекте все таки используется БЭМ повсемесно то .container, [class^=«container--»], [class*=" container--"] применится только к классам которые начинаются на container--, независимо от расположения этого класса в атрибуте class. В БЭМ классы с модификаторами вседа используются совместно с классами блока или элемента, и никогда сами по себе, а значит container-- должен применяться совместно с .container и раз так, то поведение .container, [class^=«container--»], [class*=" container--"] как раз играет на руку тем кто использует БЭМ. Кроме того эту конструкцию нужно использовать только тогда когда есть необходимость в модификаторах, так что лишний раз можно не писать.
zorro1211
0
Вот достаточно интересное решение (https://github.com/JamieMason/shrinkpack), которое решает группу проблем:
1) не нужно постоянно скачивать с registry.npmjs.org
2) Каждый пара пакет/версия может быть добавлена в репозиторий как единый тар-архив, что помогает избегать проблем с сотнями файлов во время слияния веток.
3) Помогает избегать проблемы кроссплатформенных зависимостей в репозитории
4) Расширяет возможности npm shrinkwrap
zorro1211
0
Вот в этой статье я разобрал как устроен `co`. Единственный минус — статья на английском.
zorro1211
+2
github.com/facebook/react/wiki/Sites-Using-React среди этих компаний никто так и не дотянул инерпрайз уровня, судя по вашим словам.
zorro1211
+5
Вас никто не заставляет переходить, живите с msbuild'ом и будьте счастливы.
К сожалению столкнулся на работе с подобным вашему отношением к javascript и различным технологиям на его основе. На ваше и подобным вам горе или счастье пока c# в браузере не выполняется а .net надстроки вокруг javascript весьма сильно устарели, так как многим бекэнд разрабочтикам не понять нужд фронтэнда и поэтому у них нет возможности, знаний и желания сделать что-то действительно удобное и полезное. Также нету желания совершенствовать существующие инструмены для фронтэнда (кстати не у всех в .net мире такое же представление как у вас, вот взять например автора этой статьи). Также для расширения инструментов в .net уже у фронтэнд разрабочиков нету знаний и желания разбираться как в .net коде что-то подкрутить. Вот поэтому с приходом node.js у многих разработчиков знающих js появилась возможность поправить положение и судя по ежедневным статьям о различных технологиях (например упомянутой gulp) и инструментах на базе js, дела идут очень успешно, так что это win-win для всех. Вы будете фокусироваться на бекэнд разработке и использовать инструменты которые вам удобны, а фронтэнд разработчики позаботятся о своей части.
zorro1211
0
А сколько у вас по времени занимает запрос? Спрашиваю потому что наткнулся вот на такую интересную библиотеку, которыя обещает 32 кратный прирост приизводительности в случае интеграции node & в данном случае .net — tjanczuk.github.io/edge/#/35. Хотя когда речь об ~1.5 мс vs. ~0 мс, то наверное не особо важно =)