Использование именованных экспортов не решает эту проблему полностью. Импорты с "as" тоже придется править руками. И на практике, скорее всего, их просто забудут исправить. Вместо решения, вы бежите от проблемы, создавая новые.
Полный путь к файлу создает уникальный скоуп для всего содержимого. Всё в файле должно именоваться относительно этого контекста. Тавтология не создаст глобально уникальных имен (если только вы не в несете полный путь в каждое имя).
И по этой ссылке, также не объясняется, как дефолтный экспорт мешает рефакторингу.
Экспорт по-умолчанию делает невозможным крупномасштабный рефакторинг, так как импортируемый модуль может называться по-разному в каждом месте (включая опечатки).
Какая разница, как называется импортируемый модуль, если IDE ищет семантически? К тому же, именованный импорт тоже может называться по-разному.
Объясните, пожалуйста, что значит «явная связь»? Почему в моём примере она неявная? И почему это вообще важно?
По ссылке всё прочитал, но не понял, о каких проблемах с рефакторингом вы говорите.
Напоретесь разок — поймете.
Хотелось бы понять, на что я могу напороться до того, как это произойдёт.
Из этого списка так и не понятно, на что можно напороться при рефакторинге? Если при рефакторинге вы используете текстовый поиск, вы также напоритесь и с именованными экспортами (имя можно поменять при импорте, или разные модули могут экспортировать одинаковые имена). А если пользуетесь семантическим поиском, то ему какая разница?
Но карантин предполагает, что большинство работать не будет. Я пытаюсь понять именно смысл введения карантина. Либо его отменят и рост заболевших продолжится, либо надо сидеть дома годы.
Т.е. вы исходите из того, что 15% в Германии уже переболели? Чего тогда вообще бояться, если у них 5000 смертей на 15% населения? Это а разы меньше, чем летальность гриппа.
Если что, я не утверждаю, что коронавирус менее летален, чем грипп. Судя по общей статистики смертей Италии, это не так. Хотя может быть и там, как-то умудрились искуственно повысить смертность с помощью карантина и паники. Но скорее всё-таки исследование, на которое вы ссылаетесь, несостоятельно.
Так что моё утверждение остаётся прежним: люди скорее умрут от голода, чем будет изобретено лекарство/вакцина или все медленно переболеют, не перегружая здравоохранение. Наверное, я чего-то не понимаю. Надеюсь, что кто-нибудь объяснит.
Тоесть вы предлагаете сидеть дома, пока не будет вакцины или лекарства? Это как минимум год. Вы считаете, что возможно большей части населения не работать в течение года? А если лекарства или вакцины не будеи создано, то сидеть 10 лет?
Пожалуйста, объясните, какой смысл в растягивании эпидемии, если понадобится десяток лет, чтобы переболели все? Люди раньше умрут с голоду, даже если через год-два появится вакцина.
Это называется "компонентный подход". Раньше не было удобного способа разбивать код на основе логических связей. Всё что мы могли — это разделить HTML, CSS и JS.
Хочу добавить пять копеек: в веб-версии отсутствует функция ответа на сообщение, т.е. нельзя своё сообщение связать с чужим, как в вотсапе или телеграме. А ещё каким-то невероятным способом они сломали копирование выделенного текста. При чем работает по Ctrl+C (по-моему, через раз), а через контекстное меню — нет. Не представляю, зачем этим пользоваться по собственной воле.
Спасибо за упоминание, не знал что fluent умеет читать из journald. Есть ещё journalbeat. Несколько месяцев назад там был неприятный баг, дублирующий сообщения. Но сейчас всё хорошо работает.
Хотелось на конечный интерфейс к логам посмотреть. Не получилось быстро нагуглить. Как выше уже написали, Kibana для чтения логов прекрасна. По некоторым причинам использую вместо неё Graylog и не перестаю плеваться. Интересно, может ли Grafana составить конкуренцию.
Полностью разделяю ваш восторг от ClickHouse. У нас он заменил связку ElasticSearch+Spark. Я был в шоке, когда увидел, что ClickHouse с легкостью делает в реальном времени то, для чего требовались кластеры ES и DataBricks и много минут на перегонку данных.
Хочу поделиться одним из кейсов. Из API стороннего сервиса грузим отчёт в десятки тысяч строк. Потом этот отчёт мапится в миллионы строк. Памяти категорически не хватает, а нужно сделать агрегацию, прежде чем сложить всё в базу. Думал, что придётся писать модуль на Сях. Но ClickHouse оказался просто магией: загрузил во временную таблицу промежуточные данные и сагрегировал за секунды. Сами данные съедали в разы меньше, чем удалось выжать из Питона с NumPy, но во время агрегации памяти уже не хватало. Достаточно поменять настройку КликХауса, и он волшебным образом как-то всё проделывает с использованием диска, по-прежнему за считанные секунды.
Так что рекомендую попробовать не только как хранилище, но и как число-дробилку.
Именно поэтому и костыль. То что вы описали, это костыль для костыля. Например, страниц может быть запредельно много. Да и SSR нужен не только для SEO.
Я сам предпочитаю обычный импорт из-за простоты, но в данном случае нужно признать, что это может вызвать проблемы. Лучше доставать стор из контекса реакта.
Костылем я назвал puppeter.
Разговор был не о готовой архитектуре, а о том, что мы строим под приложение. Но если хотите пример хорошей архитектуры, где уже решены эти вопросы, посмотрите фреймворк DerbyJS.
Использование именованных экспортов не решает эту проблему полностью. Импорты с "as" тоже придется править руками. И на практике, скорее всего, их просто забудут исправить. Вместо решения, вы бежите от проблемы, создавая новые.
Полный путь к файлу создает уникальный скоуп для всего содержимого. Всё в файле должно именоваться относительно этого контекста. Тавтология не создаст глобально уникальных имен (если только вы не в несете полный путь в каждое имя).
Вам что-то хотя бы отдаленно похожее приходилось видеть?
Какая разница, как называется импортируемый модуль, если IDE ищет семантически? К тому же, именованный импорт тоже может называться по-разному.
По ссылке всё прочитал, но не понял, о каких проблемах с рефакторингом вы говорите.
Хотелось бы понять, на что я могу напороться до того, как это произойдёт.
Что ей мешает искать дефолтные импорты?
Что вы подразумеваете под словом «явно»?
Вполне явно импортирует с именем Component.
Если что, я не утверждаю, что коронавирус менее летален, чем грипп. Судя по общей статистики смертей Италии, это не так. Хотя может быть и там, как-то умудрились искуственно повысить смертность с помощью карантина и паники. Но скорее всё-таки исследование, на которое вы ссылаетесь, несостоятельно.
Так что моё утверждение остаётся прежним: люди скорее умрут от голода, чем будет изобретено лекарство/вакцина или все медленно переболеют, не перегружая здравоохранение. Наверное, я чего-то не понимаю. Надеюсь, что кто-нибудь объяснит.
Тоесть вы предлагаете сидеть дома, пока не будет вакцины или лекарства? Это как минимум год. Вы считаете, что возможно большей части населения не работать в течение года? А если лекарства или вакцины не будеи создано, то сидеть 10 лет?
Пожалуйста, объясните, какой смысл в растягивании эпидемии, если понадобится десяток лет, чтобы переболели все? Люди раньше умрут с голоду, даже если через год-два появится вакцина.
И что они будут делать дальше?
Это называется "компонентный подход". Раньше не было удобного способа разбивать код на основе логических связей. Всё что мы могли — это разделить HTML, CSS и JS.
Хочу добавить пять копеек: в веб-версии отсутствует функция ответа на сообщение, т.е. нельзя своё сообщение связать с чужим, как в вотсапе или телеграме. А ещё каким-то невероятным способом они сломали копирование выделенного текста. При чем работает по Ctrl+C (по-моему, через раз), а через контекстное меню — нет. Не представляю, зачем этим пользоваться по собственной воле.
Хотелось на конечный интерфейс к логам посмотреть. Не получилось быстро нагуглить. Как выше уже написали, Kibana для чтения логов прекрасна. По некоторым причинам использую вместо неё Graylog и не перестаю плеваться. Интересно, может ли Grafana составить конкуренцию.
Полностью разделяю ваш восторг от ClickHouse. У нас он заменил связку ElasticSearch+Spark. Я был в шоке, когда увидел, что ClickHouse с легкостью делает в реальном времени то, для чего требовались кластеры ES и DataBricks и много минут на перегонку данных.
Хочу поделиться одним из кейсов. Из API стороннего сервиса грузим отчёт в десятки тысяч строк. Потом этот отчёт мапится в миллионы строк. Памяти категорически не хватает, а нужно сделать агрегацию, прежде чем сложить всё в базу. Думал, что придётся писать модуль на Сях. Но ClickHouse оказался просто магией: загрузил во временную таблицу промежуточные данные и сагрегировал за секунды. Сами данные съедали в разы меньше, чем удалось выжать из Питона с NumPy, но во время агрегации памяти уже не хватало. Достаточно поменять настройку КликХауса, и он волшебным образом как-то всё проделывает с использованием диска, по-прежнему за считанные секунды.
Так что рекомендую попробовать не только как хранилище, но и как число-дробилку.
Я сам предпочитаю обычный импорт из-за простоты, но в данном случае нужно признать, что это может вызвать проблемы. Лучше доставать стор из контекса реакта.
Костылем я назвал puppeter.
Разговор был не о готовой архитектуре, а о том, что мы строим под приложение. Но если хотите пример хорошей архитектуры, где уже решены эти вопросы, посмотрите фреймворк DerbyJS.