ну вообще красавчики, хотелось бы мне поработать в такой компании в начале карьеры для опыта. если не секрет сколько у вас архитекторов/конструкторов/смежников пользуются системой? вот вы говорите что конструктор не видит архитектурных семейств. а есть у конструктора возможность увидеть готовую модель - со всеми сетями, мафами и т.д., что бы понимать что получилось в итоге?
еще один вопрос к вам - вы разрабатываете документацию на ваши семейства? как вы ее храните? понятно что на условный умывальник это не актуально, а на вот что-то более-менее серьезное и неочевидное, что имеет ограничения к контексту применения (например это семейство нужно использовать со стеной, это привязывается к полу, ну и т.д. как пример системных семейств вроде похожих но разных - архитектурные и несущие колонны)?
ну вот как бы и на хабре освещалось немного, работают в России над BIM. количество человек в разработке - ну такой себе показатель, это скорее для поддержки легаси имхо + менеджеры + продажники + поддержка. я вообразить до сих пор не могу как Линус Торвальдс в одного столько работы проделал, да и еще были люди старой школы. ну и Илон Маск показал - выгнал кучу людей когда твиттер купил - и ничего, даже лучше стало. я не хочу учить новую программу, староват уже для этого. но из первых уст было бы интересно узнать про реальный опыт. вообще мое мнение, что BIM - это поворот не туда. ну не нужно оно никому в реальности. я искренне не понимаю почему не поддерживаются типовые серии - все уже давно изобретено до нас, и проверено десятками лет. актуализировать под современные нагрузки, методики расчета и материалы (жилые дома, сады, мосты) - и незачем стольким людям учиться проектировать за счет строителей. качество проектирования в моем регионе все ниже и ниже, эти проектасты (не всех под одну гребенку, но в моем регионе к сожалению 90% именно проектасты) заявляют - нам мало денег за авторский надзор, нам это не интересно (сами же в сводники цену на свою работу закладывают) и сливаются еще до стадии строительства, когда все их недоработки вылезают наружу. было время сам работал в проектной конторе, понимаю почему так происходит, но это совсем другая история.
я не архитектор, я в ПТО работаю по большей части. Revit хорошо тем, что позволяет мне пересчитывать объемы. насчет российских BIM решений не подскажу, знаю о них только из гугла. вообще не понимаю в чем эта сила BIM, от проектировщиков чертежей в автокаде то не получить. вот и выбрал для себя путь Revit - вполне себе. но санкции. вот и думал что от вас узнаю про аналоги. у вас есть опыт использования BIM моделей дальше после проектирования? что бы и строители пользовались, и заказчики?
вот никогда не понимал этот ртутный барометр. как может ртуть опуститься в запаянной трубке, откуда взяться «вакууму»? если б там было хоть немного воздуха и он расширился — понятно. и если взять запаянные трубки с ртутью для барометра разной длины, скажем 1 и 5 метров, наполнить ртутью и перевернуть так что бы нижние концы были на одном уровне — и что в одной будет 240 (1000-760) мм вакуума а в другой 4240 (5000-760)? эх почему в школе не проходили физику вакуума.
а мне кажется наоборот, ввиду распространения такого подхода (использание знака умножения), особенно не так часто используемого в обычном тексте, у человека вырабатывается рефлекс что это именно и есть кнопка «закрыть», и он не запутается.
зачем вы используете inject когда рекомендуется использовать react.context?
Warning: It is recommended to use React.createContext instead! It provides generally the same functionality, and Provider / inject is mostly around for legacy reasons
Ну вообще это элементарно, когда под рукой есть Javascript и WebSocket's(не обязательно, но с ними гораздо лучше). И без разница какой уровень вложенности в ваших массивах и объектах.
— я видимо недостаточно ясно выразился. с механизмом доставки нет проблем, сокеты или что-то еще. вопрос был про данные, как вы предлагаете отслеживать изменения в данных и обновлять небольшие их фрагменты, только то что изменилось средствами голого mobx? или будете передавать весь документ целиком, и не важно что некоторые пользователи уже тоже вносят изменения?
Typescript / Flow знает о структуре данных.
— вы путаете мягкое и теплое, типизация не добавит вам более безопасных способов работы с данными, в отличии от MST, который и в рантайме будет это делать.
Вообщем в дальнейшей дискуссии не вижу смысла. И доказывать вам что-то, тоже не вижу смысла.
т.е. вы видите смысл в разбрасывании голословными утверждениями вроде
Вообщем mobx-state-tree нафиг не нужен, он только мешает и делает код придурковатым, вместо того чтобы писать код максимально простым и понятным.
не приведя никаких аргументов?
я тоже не собираюсь вам ничего доказывать, это комментарии для новичков, которые только начинают погружаться в реакт, но нахожу несколько странным вашу позицию вроде «статья не моя, я лишь перевел, и все равно что там написано — я не при делах, и вообще пишу код не так как предлагают в этой статье».
MST реализовал все велосипеды, которые вы скорее всего напишете поверх mobX, если столкнетесь с более сложными структурами данных, кстати он тоже написан поверх mobX. Эти подходы идут по возрастании сложности данных: стейт реакта-> mobX-> MST. Кстати Typescript тоже поддерживается в MST.
Вот простой пример. Допустим у нас есть документ с данными, он хранится в массиве на сервере. С ним одновременно работают несколько человек в реальном времени. Один пользователь поменял у себя в модели какой-то элемент массива. Вопрос: как вы передадите изменения от этого пользователя всем остальным? как организовать удаление/обновление/создание новых элементов сразу у всех пользователей данного документа (будете писать экшены в духе редакса?)? а когда сложность и глубина структуры данных начнет расти?
MST знает о структуре данных, в отличие от mobX, что сильно упрощает работу с ними.
И про хуки. Ваша статья называется «Контролируемые и неконтролируемые компоненты в React не должны быть сложными». функции + хуки -> меньше кода, выше наглядность -> снижение сложности.
Ну вот, вы же сами про реактовский стейт менеджмент статью писали (кстати форму валидировать самое то, разве нет? а после валидации и модель обновить. Да и переиспользуемые компоненты без локального стора сложновато написать. Да и бывают свойства в компоненте отвечающие чисто за косметику, не тянуть же их в глобальный стор), а хуки лично мне много приятнее использовать, в сравнении с классами (после них и мысли не возникает использовать классы). А теперь отходите в сторону. Я согласен, что есть решения для глобального стейта и получше (реакт же позиционируется как бы для презентаций), но раз пошел такой разговор, то еще лучшее mobx-state-tree. Там и патчи (очень помогает если вы свою модель с сервером синхронизируете, когда один документ редактируют несколько пользователей одновременно например), и снапшуты, и много чего еще вкусного.
«Хуки не меняют ваши знания о концепциях в React. Вместо этого, хуки предоставляют более прямой доступ к API уже знакомых вам понятий: пропсов, состояния, контекста, рефов, и жизненного цикла. Мы также рассмотрим мощный способ компоновать эти понятия с помощью хуков.»
У вас не опечатка в месте:
2, 2 + 3 1, 2 + 3 2, 2 + 3 3, 2 + 3 4. То есть, 2, 5, 11, 29, 83
логично начать прогрессию не с 2 а с 2+3^0=2+1=3, в итоге 3, 5, 11…
я с Тинькофф пол года. постоянно добавляются акции и облигации новые. комиссии 0.3 % от сделки + 100 руб. в месяц. или 0,05% от сделки + 300 руб. в месяц, какой тариф выберете. очень ими доволен, весь портфель в моем смартфоне.
ну вообще красавчики, хотелось бы мне поработать в такой компании в начале карьеры для опыта. если не секрет сколько у вас архитекторов/конструкторов/смежников пользуются системой? вот вы говорите что конструктор не видит архитектурных семейств. а есть у конструктора возможность увидеть готовую модель - со всеми сетями, мафами и т.д., что бы понимать что получилось в итоге?
еще один вопрос к вам - вы разрабатываете документацию на ваши семейства? как вы ее храните? понятно что на условный умывальник это не актуально, а на вот что-то более-менее серьезное и неочевидное, что имеет ограничения к контексту применения (например это семейство нужно использовать со стеной, это привязывается к полу, ну и т.д. как пример системных семейств вроде похожих но разных - архитектурные и несущие колонны)?
https://habr.com/ru/companies/sberbank/articles/911312/
https://habr.com/ru/companies/ascon/articles/725180/
ну вот как бы и на хабре освещалось немного, работают в России над BIM. количество человек в разработке - ну такой себе показатель, это скорее для поддержки легаси имхо + менеджеры + продажники + поддержка. я вообразить до сих пор не могу как Линус Торвальдс в одного столько работы проделал, да и еще были люди старой школы. ну и Илон Маск показал - выгнал кучу людей когда твиттер купил - и ничего, даже лучше стало. я не хочу учить новую программу, староват уже для этого. но из первых уст было бы интересно узнать про реальный опыт. вообще мое мнение, что BIM - это поворот не туда. ну не нужно оно никому в реальности. я искренне не понимаю почему не поддерживаются типовые серии - все уже давно изобретено до нас, и проверено десятками лет. актуализировать под современные нагрузки, методики расчета и материалы (жилые дома, сады, мосты) - и незачем стольким людям учиться проектировать за счет строителей. качество проектирования в моем регионе все ниже и ниже, эти проектасты (не всех под одну гребенку, но в моем регионе к сожалению 90% именно проектасты) заявляют - нам мало денег за авторский надзор, нам это не интересно (сами же в сводники цену на свою работу закладывают) и сливаются еще до стадии строительства, когда все их недоработки вылезают наружу. было время сам работал в проектной конторе, понимаю почему так происходит, но это совсем другая история.
я не архитектор, я в ПТО работаю по большей части. Revit хорошо тем, что позволяет мне пересчитывать объемы. насчет российских BIM решений не подскажу, знаю о них только из гугла. вообще не понимаю в чем эта сила BIM, от проектировщиков чертежей в автокаде то не получить. вот и выбрал для себя путь Revit - вполне себе. но санкции. вот и думал что от вас узнаю про аналоги. у вас есть опыт использования BIM моделей дальше после проектирования? что бы и строители пользовались, и заказчики?
это все конечно интересно, но почему Revit? я и сам люблю Revit, но мы же под санкциями. не задумывались о переходе на отечественные BIM технологии?
как же так?
Warning: It is recommended to use React.createContext instead! It provides generally the same functionality, and Provider / inject is mostly around for legacy reasons
— вы путаете мягкое и теплое, типизация не добавит вам более безопасных способов работы с данными, в отличии от MST, который и в рантайме будет это делать.
т.е. вы видите смысл в разбрасывании голословными утверждениями вроде не приведя никаких аргументов?
я тоже не собираюсь вам ничего доказывать, это комментарии для новичков, которые только начинают погружаться в реакт, но нахожу несколько странным вашу позицию вроде «статья не моя, я лишь перевел, и все равно что там написано — я не при делах, и вообще пишу код не так как предлагают в этой статье».
Вот простой пример. Допустим у нас есть документ с данными, он хранится в массиве на сервере. С ним одновременно работают несколько человек в реальном времени. Один пользователь поменял у себя в модели какой-то элемент массива. Вопрос: как вы передадите изменения от этого пользователя всем остальным? как организовать удаление/обновление/создание новых элементов сразу у всех пользователей данного документа (будете писать экшены в духе редакса?)? а когда сложность и глубина структуры данных начнет расти?
MST знает о структуре данных, в отличие от mobX, что сильно упрощает работу с ними.
И про хуки. Ваша статья называется «Контролируемые и неконтролируемые компоненты в React не должны быть сложными». функции + хуки -> меньше кода, выше наглядность -> снижение сложности.
И есть проблемы с асинхронным обновлением стейта.
Вот цитата со страницы реакта:
Вот ваш компонент на хуках:
Ну разве не красота?
именно Ньютон изобрел телескоп-рефлектор, и сделал много астрономических открытий
2, 2 + 3 1, 2 + 3 2, 2 + 3 3, 2 + 3 4. То есть, 2, 5, 11, 29, 83
логично начать прогрессию не с 2 а с 2+3^0=2+1=3, в итоге 3, 5, 11…