Да нет же. "В идеале" они должны переименовываться именно вместе. А вот всякие особенности проекта уже могут мешать нам это сделать. И тогда архитектура, конечно, не должна этому препятствовать.
Да, это немного словоблудие, но за ним есть и практический смысл. Нужно различать причины, по которым вы не хотите переименовывать столбец. Если эти причины устранимы, то с ними нужно бороться и обеспечить быстрое и простое изменение схемы бд. Например, если вы избегаете переименования из-за того, что у вас нет типизации кода, или миграции бд нужно писать руками, то проблема вовсе не в связанности бэкенда с фронтендом.
То что вы говорите для многих тоже как догма. Но посмотрите под другим углом: если поле на фронте нужно переименовывать, то почему в базе должно оставаться старое название? Ситуации могут быть очень разные, но кажется, что вы хотите вместо переименовывания столбца оставить техдолг. У поля со временем изменился смысл или просто нашелся более подходящий нейминг, а вы хотите в базе оставить устаревшее название, потому что так проще.
Прошу воспринимать без категоричности. Повторю, что проекты могут быть разные, где-то переименовывать столбец действительно очень дорого. На нашем проекте мы придерживаемся архитектуры, при которой можно делать и так, как вы описываете (максимально избегать повторений) и с легкостью отойти от схемы базы, не добавляя при этом бойлерплейта.
Ребят, привет! Джва года ждал этой статьи. Пока ожидания оправдываются, очень интересно.)
Больно слышать про тормоза при сериализации в протобаф.) Не копали причины? Просто питоновая либа медленная? Вроде ж в низкоуровневых языках протобаф быстрее.
Проблема в том, что инструмент должен подстраиваться под разработчика, а не разработчик под инструмент. Правильный вопрос, не "а что не так", а "почему реакт не может соптимизировать этот код, чтобы не делать бессмысленную работу в рантайме"?
Не сравнивали с ts-sql-query? Выглядит очень похоже, только подходы немного разные. На первый взгляд кажется, что типизация киселя через строки лаконичнее, но где-то может быть ограничена в возможностях. Есть запросы, которые нельзя на нем составить или которые не валидируются по типам?
А что делать, если для реакции не хватает только той информации, что есть в базе? Допустим, если нужно еще знать пользователя, который внес эти изменения?
В таком случае её можно было и не решать вообще. Переименовывание и так достаточно редкий кейс. И, повторюсь, при вашем подходе, вы с большой вероятностью забудете поправить `as` импорты, потому что будете полагаться на IDE.
Ну, во-первых, таким импорты будут явно указаны,
Опять это слово «явно». Чем `import Name from` неявен? Тут явно написано, что объект, экспортируемый по дефолту, нужно импортировать с именем Name.
плюс в начале файла можно будет увидеть родное название.
И в дефолтном импорте можно увидеть название файла.
Какие именно «новые» проблемы созданы?
Отсутствие строгой системы в именовании.
Важно писать так, чтобы они были уникальные в местах, где используются.
Т.е. вы про каждый экспорт должны думать, а где и с чем вместе он будет использоваться? Экспорт — такое же локальное имя, как и всё остальное в файле. Он находится в том же смысловом контексте, и должен именоваться аналогично со всем остальным, без добавления контекста в имя. Иначе возникает неконсистентность в именах, которая всё равно не избавит от коллизий имён, а значит `as` придётся использовать, и все проблемы никуда не деваются. Вы не решили проблему, а замели пыль под кровать.
Использование именованных экспортов не решает эту проблему полностью. Импорты с "as" тоже придется править руками. И на практике, скорее всего, их просто забудут исправить. Вместо решения, вы бежите от проблемы, создавая новые.
Полный путь к файлу создает уникальный скоуп для всего содержимого. Всё в файле должно именоваться относительно этого контекста. Тавтология не создаст глобально уникальных имен (если только вы не в несете полный путь в каждое имя).
И по этой ссылке, также не объясняется, как дефолтный экспорт мешает рефакторингу.
Экспорт по-умолчанию делает невозможным крупномасштабный рефакторинг, так как импортируемый модуль может называться по-разному в каждом месте (включая опечатки).
Какая разница, как называется импортируемый модуль, если IDE ищет семантически? К тому же, именованный импорт тоже может называться по-разному.
Объясните, пожалуйста, что значит «явная связь»? Почему в моём примере она неявная? И почему это вообще важно?
По ссылке всё прочитал, но не понял, о каких проблемах с рефакторингом вы говорите.
Напоретесь разок — поймете.
Хотелось бы понять, на что я могу напороться до того, как это произойдёт.
Из этого списка так и не понятно, на что можно напороться при рефакторинге? Если при рефакторинге вы используете текстовый поиск, вы также напоритесь и с именованными экспортами (имя можно поменять при импорте, или разные модули могут экспортировать одинаковые имена). А если пользуетесь семантическим поиском, то ему какая разница?
В наксте хуком называется совершенно другое. Это компосаблы.
Да нет же. "В идеале" они должны переименовываться именно вместе. А вот всякие особенности проекта уже могут мешать нам это сделать. И тогда архитектура, конечно, не должна этому препятствовать.
Да, это немного словоблудие, но за ним есть и практический смысл. Нужно различать причины, по которым вы не хотите переименовывать столбец. Если эти причины устранимы, то с ними нужно бороться и обеспечить быстрое и простое изменение схемы бд. Например, если вы избегаете переименования из-за того, что у вас нет типизации кода, или миграции бд нужно писать руками, то проблема вовсе не в связанности бэкенда с фронтендом.
То что вы говорите для многих тоже как догма. Но посмотрите под другим углом: если поле на фронте нужно переименовывать, то почему в базе должно оставаться старое название? Ситуации могут быть очень разные, но кажется, что вы хотите вместо переименовывания столбца оставить техдолг. У поля со временем изменился смысл или просто нашелся более подходящий нейминг, а вы хотите в базе оставить устаревшее название, потому что так проще.
Прошу воспринимать без категоричности. Повторю, что проекты могут быть разные, где-то переименовывать столбец действительно очень дорого. На нашем проекте мы придерживаемся архитектуры, при которой можно делать и так, как вы описываете (максимально избегать повторений) и с легкостью отойти от схемы базы, не добавляя при этом бойлерплейта.
Это можно. Но вместо throw нужно использовать функцию `(ex) => {throw ex}`
А почему секунду не определят так, чтобы в среднем сутки были 24 часа? Или длительность суток настолько нестабильна, что это нельзя сделать?
Ребят, привет! Джва года ждал этой статьи. Пока ожидания оправдываются, очень интересно.)
Больно слышать про тормоза при сериализации в протобаф.) Не копали причины? Просто питоновая либа медленная? Вроде ж в низкоуровневых языках протобаф быстрее.
Проблема в том, что инструмент должен подстраиваться под разработчика, а не разработчик под инструмент. Правильный вопрос, не "а что не так", а "почему реакт не может соптимизировать этот код, чтобы не делать бессмысленную работу в рантайме"?
Я не новорег. Можете мне рассказать, что за тренды?
Не сравнивали с ts-sql-query? Выглядит очень похоже, только подходы немного разные. На первый взгляд кажется, что типизация киселя через строки лаконичнее, но где-то может быть ограничена в возможностях. Есть запросы, которые нельзя на нем составить или которые не валидируются по типам?
А что делать, если для реакции не хватает только той информации, что есть в базе? Допустим, если нужно еще знать пользователя, который внес эти изменения?
Подскажите, пожалуйста, как вы обесточиваете плиту? Контактором?
В таком случае её можно было и не решать вообще. Переименовывание и так достаточно редкий кейс. И, повторюсь, при вашем подходе, вы с большой вероятностью забудете поправить `as` импорты, потому что будете полагаться на IDE.
Опять это слово «явно». Чем `import Name from` неявен? Тут явно написано, что объект, экспортируемый по дефолту, нужно импортировать с именем Name.
И в дефолтном импорте можно увидеть название файла.
Отсутствие строгой системы в именовании.
Т.е. вы про каждый экспорт должны думать, а где и с чем вместе он будет использоваться? Экспорт — такое же локальное имя, как и всё остальное в файле. Он находится в том же смысловом контексте, и должен именоваться аналогично со всем остальным, без добавления контекста в имя. Иначе возникает неконсистентность в именах, которая всё равно не избавит от коллизий имён, а значит `as` придётся использовать, и все проблемы никуда не деваются. Вы не решили проблему, а замели пыль под кровать.
Использование именованных экспортов не решает эту проблему полностью. Импорты с "as" тоже придется править руками. И на практике, скорее всего, их просто забудут исправить. Вместо решения, вы бежите от проблемы, создавая новые.
Полный путь к файлу создает уникальный скоуп для всего содержимого. Всё в файле должно именоваться относительно этого контекста. Тавтология не создаст глобально уникальных имен (если только вы не в несете полный путь в каждое имя).
Вам что-то хотя бы отдаленно похожее приходилось видеть?
Какая разница, как называется импортируемый модуль, если IDE ищет семантически? К тому же, именованный импорт тоже может называться по-разному.
По ссылке всё прочитал, но не понял, о каких проблемах с рефакторингом вы говорите.
Хотелось бы понять, на что я могу напороться до того, как это произойдёт.
Что ей мешает искать дефолтные импорты?
Что вы подразумеваете под словом «явно»?
Вполне явно импортирует с именем Component.