Где посмотреть как включить такой вот Clock в React компонент, например как children?

Спасибо. Можно посмотреть полный код SW?

Мне не кажется что этот комментарий тянет на отличный. Из кода и так понятно что он делает. А решать архитектурные проблемы комментариями вообще плохая идея. Лучше продумать обязательность/необязательность key.
Разрешите пример хорошего комментария, на мой взгляд:

// not using Number.isFinite here because it must work in IE11 without polifill
if(!isFinite(arg)) return; 
...

Тут четко понятно почему сделано так а не иначе, как раз в духе «не что, а зачем»

Позволю себе совет. Перепишите на typescript. Ну и еще один, попросите опытных товарищей сделать codereview вашему коду. Я пробежался по диагонали, есть явные места где стоит чуть переделать, например

//....
 return nstd.Structure.sort((a, b) => {
      if (a.lkey > b.lkey) return 1
      if (a.lkey < b.lkey) return -1
      return 0
    })

// better replace with 
 return nstd.Structure.sort((a, b) => a.lkey - b.lkey )

уверен что будут и более веские замечания.

Чего это вы так взбеленились? Это ваши модули? С чего вы взяли что я не создаю issue? Я на такое ругался еще со времен jquery плагинов и browserify, который этим то же страдал даже в большей степени.
К тому же, обычно лишние файлы не видно, нужно специально лезть в модули, что делается крайне редко. Замечать это начинаешь когда inodes заканчиваются и тормозит IDE. Вот тогда и подбешивает, смотришь на размеры папок и сносишь модули в старых проектах.

Люто плюсую. Бесит неимоверно. Кому-то не хватает мозгов прописать files в package.json и мы получаем +100500 кб нафиг ненужного барахла

Почему JavaScript-программисты испытывают проблемы при использовании ключевого слова this?

Программисты не испытывают проблем при использовании слова this. Проблемы испытывают недопрограммисты. А вообще, я бы на собесах просил написать три функции для числа фибоначчи: рекурсивно, динамическим программированием и с помощью генераторов. Если человек это все знает и умеет, с высокой вероятностью он программист. Недостаток знаний по либам и тулзам не важен. Решать гуано-кодище в уме, что выведет фигня за которую в реальности нужно рубить пальцы… Зачем такие вопросы, мне не понятно.

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

Абсолютно согласен.
И про деньги согласен. Но это нужно обговаривать. И на входе не строки, а числа.

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

Еще хуже вариант. Я б такому калькулятору точно не доверял.
Давайте сразу уточним, речь идет о float, не об int. Смотрите, я делю 100 на 3. Получаю 33 и 3 в периоде. А вижу

["33.333", "33.333", "33.334" ]

Как вы мне объясните что у меня одно(последнее) число больше чем первые два? Это точно подтасовка.

С другой стороны, умножая 33.333 * 3 я получу «100.00» или «99.999».

(33.333 * 3).toFixed(3) // "99.999"
(33.333 * 3).toFixed(2) // "100.00"
(33.333 * 3).toFixed(1) // "100.0"

Видно что происходит? Потеря точности неизбежна. И вот этот аргумент, что пользователь и программе не доверяет, и сам считать не умеет, ну извинити…

Это, опять же, совершенно другая задача.
Разбить целое на целые доли ну вот нифига не тоже самое что вывести массив процентов в строках с округлением до 3 знаков. Я даже рад что не прошел то интервью. Если просят ставят одну задачу, а решение ожидают от другой, то я наверное никогда так не смогу.

Ну очевидно, первое что приходит — не применять округление для промежуточных результатов. Округление — последняя операция. И с каких это пор подгонка результата вычислений под желаемое — нормальная операция?

Не переворачивайте исходные условия, пожалуйста. Задача звучала не так. То что вы просите — другая задача. Задача была вернуть массив округленных строк.
ЗЫ А вот почему потом вдруг эти строки начинают участвовать в математике, для меня тоже вопрос.

Инженерно? Хм… Про погрешности я не буду тут рассказывать, но это не инженерно, поверьте.
Во первых, правильно будет форматировать результат, а не округлять в промежуточных вычислениях.
Во вторых. результат, как я уже упомянул — строки. Нахрена вам строки складывать? Если вы знаете что потом с результатом будут дальше проводиться вычисления, зачем округлять?
В третьих, даже если так поступать, почему погрешность прибавлять к последнему? Чем последний элемент лучше чем первый, или второй, или рандомный?
Это не математика, это фальсификация. Такими математиками только печь топить.