Совет 2. Приводит к двойном проходу по коллекции. Если использовать метод reduce(), то проблема решается и лаконичность не теряется.
Совет 3 и 4. Сократили количество букавок, но вот далеко не всем понятно, что это всего лишь операции преобразования в строку и парсинга строки. Но как говорилось выше — существуют более корректные стандартные языковые конструкции.
Совет 7. А за такой совет вообще по этапам нужно отправить, вместе с тем кто решит его использовать. Опять же, уменьшили количество букавок, но и сильно ухудшили процесс его отладки. А как известно — отладка это то, чем занимается разработчик большую часть того времени, когда не спит. И как правило, ищут и отлаживают баги те, кто их не создавал. Конечно, эта проблема не совсем актуальна для последних версий хрома, где можно поставить бряку внутри строки, но ведь есть ещё и сафари/файерфокс, и прочая нечисть, под которыми тоже нужно работать.
но я почему-то сомневаюсь, что такая большая компания как Facebook сделала бы фреймворк, не способный к A/B тестированию
С большим интересом посмотрю на фреймворк для эксперементирования от Facebook. Особенно на ту его часть, где будет решаться проблема внедрения в реакт-дерево.
Ну да, для архитектуры не ориентированной на возможность экспериментирования без релиза приложения, такого кода достаточно.
Но вот на практике всегда все сложнее. Особенно когда нужно, и часто нужно, проверить хоть какой-то потенциал гипотезы, прежде чем выделять ресурсы на реализацию ее фич.
Банально, если реализовывать приложение, совместимое с концепцией A/B-тестирования какой-либо части интерфейса, без необходимости готовить релиз для каждого эксперимента или варианта. С реактом, к сожалению, очень быстро заходишь в тупик. Именно из-за необходимости внедриться в его абстрактное дерево.
А вот с приложением, реализованном на фреймворках/либах более дружественно относящихся к DOM и веб-стандартам, такая задача легко решается, либо проблема вообще не возникает.
И да, у вэб-компонентов нет единого стандарта, что в прочем хорошо. Потому как они базируются на семействе вэб-стандартов, которые могут развиваться уже по своей собственной траектории.
Разработчик же имеет возможность выбирать ту технологию/реализацию, которая ему больше подойдет для конкретной реализации. Нужна изоляция стилей: БЭМ, linaria, Shadow DOM, выбирай что тебе удобно. Нужен встраиваемый виджет: IFrame, вэб-виджет, вэб-компонент на шедоу или лайт DOM, ну или еще что там придумаешь.
Анализируй поставленную задачу и выбирай инструмент.
Because React implements its own synthetic event system, it cannot listen for DOM events coming from Custom Elements without the use of a workaround. Developers will need to reference their Custom Elements using a ref and manually attach event listeners with addEventListener. This makes working with Custom Elements cumbersome.
Ведь это действительно, иногда превращается в ад — попытка использовать вэб-компоненты в реакте. Он их спокойно разместит в dom-дереве, привяжется к пропертям, но вот привязать обработчик кастомного события — действительно, только через рефы. Да и вообще, спека кастомных событий рождалась не для удовлетворения потребностей именно вэб-компонентов, но для удовлетворения потребностей вэб-разработчиков.
Хорошо или плохо? Реакт решает одну хорошую и важную задачу — делает строго однонаправленный поток данных. Делает он это ценой того, что он старается держать весь поток внутри своей абстракции. И любые попытки выскочить из нее — потенциальные точки нарушения направленности потока данных. Именно поэтому разработчики этой библиотеки рекомендуют использовать рефы только в крайних случаях, когда другие способы не помогли.
Реакт не дружит с вэб-стандартами, он их оборачивает своими абстракциями, считая что это единственный верный способ реализации вэб-приложений.
В тоже время, существует много кейсов, где модель реакта не так эффективна, как реализация на чистом DOM/Custom Elements
На космические программы тратятся в основном бюджетные деньги, соответственно их результаты по сути являются достоянием государства. Следовательно, граждане этого государства также должны напрямую получать результаты работы этих программ. Не только новости об абстрактных достижениях. Но и массовое производство новых технологичных решений, более эффективно решающих ежедневные проблемы, или же обходящихся дешевле в производстве, перекладывая удешевление в потребительские цены, но не в карманы полугосударственных олигархов.
Нельзя согласиться с такой точкой зрения: " А скачав его и установив, он автоматически становился легальным пользователем, которому доступны свободы изначальной GPL лицензии". Суть исходных кодов системы в том, чтобы иметь возможность проанализировать то, будешь запускать до того как это сделаешь.
Соглашение с такой точкой зрения просто напросто ведет к обессмысливанию GPL-like лицензий
Вот такой запрос как раз собой и представляет инцидент/запрос на обслуживание. По сути ITSM, как набору процессов, не важно в какой форме поступают обращения пользователей. Важно чтобы они выполнялись в рамках одних и тех же процессов в рамках оговоренных SLA
Явно, руководитель отдела поддержки не понимает, кто и за что платит/получает, зачем вообще компаниям нужны службы поддержки и какие проблемы и риски они должны решать/снижать. Это же, кстати, в любой редакции ITSM достаточно четко описано. Либо не читал определение термина Service (буковка S из ITSM), либо не понял, либо сознательно игнорирует. В любом случае, есть о чем подумать его руководителю. В любом случае… эта буковка в равной степени и к админам относится, они также живут и существуют внутри поля действия ITSM.
Легко решается многоканальностью точки входа службы поддержки. Использовать не только IP-телефонию, но и обычную, почта, чат-боты, обеспечить резервные каналы для техподдержки, на случай если саму поддержку накрыло. Здесь многое зависит от SLA к техподдержке и таланта/прозорливости ее руководителя.
Конечно, от многоканальности мало толку, если пользователь о них не знает. но здесь уже как в маркетинге — решает обилие «рекламы». Согласитесь, ведь как-то изначально пользователь узнал об основном канале связи.
Такие взаимоотношения администраторов и пользователей как правило в тех компаниях, где слыхом не слыхивали про ITSM, или же процессы реализованы через ж… у для галочки.
А что происходит с частицей, которая не падает В ЧД? Улетает в пространство? Как далеко? Может долететь до другой ЧД или почему она никак в эту не упадет? Частицы запутаны? Сохраняется запутанность после падения одной из частиц в ЧД?
Почти половина о том, как делать не надо.
Совет 2. Приводит к двойном проходу по коллекции. Если использовать метод reduce(), то проблема решается и лаконичность не теряется.
Совет 3 и 4. Сократили количество букавок, но вот далеко не всем понятно, что это всего лишь операции преобразования в строку и парсинга строки. Но как говорилось выше — существуют более корректные стандартные языковые конструкции.
Совет 7. А за такой совет вообще по этапам нужно отправить, вместе с тем кто решит его использовать. Опять же, уменьшили количество букавок, но и сильно ухудшили процесс его отладки. А как известно — отладка это то, чем занимается разработчик большую часть того времени, когда не спит. И как правило, ищут и отлаживают баги те, кто их не создавал. Конечно, эта проблема не совсем актуальна для последних версий хрома, где можно поставить бряку внутри строки, но ведь есть ещё и сафари/файерфокс, и прочая нечисть, под которыми тоже нужно работать.
С большим интересом посмотрю на фреймворк для эксперементирования от Facebook. Особенно на ту его часть, где будет решаться проблема внедрения в реакт-дерево.
Но вот на практике всегда все сложнее. Особенно когда нужно, и часто нужно, проверить хоть какой-то потенциал гипотезы, прежде чем выделять ресурсы на реализацию ее фич.
А вот с приложением, реализованном на фреймворках/либах более дружественно относящихся к DOM и веб-стандартам, такая задача легко решается, либо проблема вообще не возникает.
И да, у вэб-компонентов нет единого стандарта, что в прочем хорошо. Потому как они базируются на семействе вэб-стандартов, которые могут развиваться уже по своей собственной траектории.
Разработчик же имеет возможность выбирать ту технологию/реализацию, которая ему больше подойдет для конкретной реализации. Нужна изоляция стилей: БЭМ, linaria, Shadow DOM, выбирай что тебе удобно. Нужен встраиваемый виджет: IFrame, вэб-виджет, вэб-компонент на шедоу или лайт DOM, ну или еще что там придумаешь.
Анализируй поставленную задачу и выбирай инструмент.
Ведь это действительно, иногда превращается в ад — попытка использовать вэб-компоненты в реакте. Он их спокойно разместит в dom-дереве, привяжется к пропертям, но вот привязать обработчик кастомного события — действительно, только через рефы. Да и вообще, спека кастомных событий рождалась не для удовлетворения потребностей именно вэб-компонентов, но для удовлетворения потребностей вэб-разработчиков.
Хорошо или плохо? Реакт решает одну хорошую и важную задачу — делает строго однонаправленный поток данных. Делает он это ценой того, что он старается держать весь поток внутри своей абстракции. И любые попытки выскочить из нее — потенциальные точки нарушения направленности потока данных. Именно поэтому разработчики этой библиотеки рекомендуют использовать рефы только в крайних случаях, когда другие способы не помогли.
Реакт не дружит с вэб-стандартами, он их оборачивает своими абстракциями, считая что это единственный верный способ реализации вэб-приложений.
В тоже время, существует много кейсов, где модель реакта не так эффективна, как реализация на чистом DOM/Custom Elements
Соглашение с такой точкой зрения просто напросто ведет к обессмысливанию GPL-like лицензий
… к стати, именно процессы Incident Managment/Request Fulfilment и буксуют с самого начала, чего уж тут ожидать, что поезд вообще поедет…
Конечно, от многоканальности мало толку, если пользователь о них не знает. но здесь уже как в маркетинге — решает обилие «рекламы». Согласитесь, ведь как-то изначально пользователь узнал об основном канале связи.