А как ещё обозначить неизменяемость значения по ходу выполнения программы? Если readonly, то это непосредственно о конструкциях, а не о логике. К логике ближе понятие иммутабельности, хотя оно из области архитектуры стиля.
Дело не в том что можно присвоить, а что нет, дело в идеологии. Например, с точки зрения языка, имена для идентификаторов переменных можно задавать абсолютно любые, хоть в т_а_к_о_м кейсе. Но вы точно знаете, что наткнувшись на ПОДОБНЫЙ_КЕЙС имеете дело с константой. С той константой, что по логики приложения представляет неизменяемое значение. Замечу ещё раз что неизменяемая не по ходу выполнения программы, а по логике! Что значит по логике? Как уже сказал ранее, PI или значение типа для события, или же функция, возможно объект, который представляет из себя дефолтное значение какого-то конфига. Вот что такое константа с точки зрения программирования. Если помечать её все неизменяемые по ходу выполнения программы значения, то как тогда определить то, что явыше описал?
И Ваш пример с функцией просто идеально иллюстрирует то о чем я говорю. В то время как первый пример иллюстрирует иммутабельность.
Да ерунда же! Во всех зрелых и серьезных языках, которые лежат воснове остальных языков, с константами ассоциируются только те значения, которые реально являются константами, как например PI или строки
представляющие название событий. Зачем придумывать все заного для js и ломать устоявшиеся каноны? Иммутабельность, это совсем не константы, это стиль\архитектура.
Полностью с Вами согласен. Типизация, это прежде всего — ограничение. Это ограничение призвано не только не позволить допустить ошибку связанную с совместимостью типов, но и дать программе выйте из архитектурной колии. Ограничения в виде типизации не позволят сложить яйца в один мешок с картошкой, что пощряет javascript. Поэтому, да, не просто написать правильную декларацию для кода на js, который был спроектирован не в типизированном стиле. Для этого придется с нуля продумывать независимую от библиотеки архитектуру и каждый раз подгонять её под javascript код. А этим мало кому хочется заниматься. Но всеже кривые декларации во много раз лучше чем вовсе никакие. Без автокомплита в 2019 просто жуть. Невозможно все держать все api в голове, когда ты пишешь на огромном множестве языков моножестов лет. Все в кашу превращается и спасает только автокомплит и автодокументированние в виде деклараций.
Интересно, какие именно случаи нельзя типизировать на текущиймомент? Было такое, но где-то спару версий назад все, врде бы, решено. Разве нет?
И да, бывает так сложно, что время затрачивается всотни раз больше. Например на js участок кода можно написать за минуту, а на ts день-два уйдет. Это при условии, что создаваемый код является описанием какого-то собственного архитектурного решения. То есть такая проработка очень редко требуется при работе с библиотеками или фраймворками. А вот при их написании она необходима. И с этим нужно смерится вне зависимости от потрачего времени. Ведь всем нравится умный автокомплит восста процентах работы с библиотекой. Ведь это экономит время и деньги и самое главное — нервы. Легче будет только если код будет писать ИИ.
И странное, что в 2019 году trypescript ещё не все используют. js, если будет долго жить, то станет ts.
Скоро наступит момент, когда катироваться будут только уникальные дизайны построенные на opengl. Это произошло бы уже давно, но проблема в том, что люди способные создавать подобныедизайны уходят дв ТВ или игрострой. Но процесс не стоит на месте и все больше и больше профессиналов остаются на уровнях ниже, тем самым задавая тон. Ещё немного и дизайн будет полностью цветной, переполнен инфографикой и моушен-дизайном, 3d. И подобные приложения будут расцениваться пользователями также, как приложения десяти летней давности.
Реальность такова, что typescript уже должен стать дефакто. Не понимаю почему этого ещё не произошло. Энтерпрайз в любом случае за c#. Питон… Питон должен резко взлететь, так как его пропагандируют как скриптовый язык для набирающей популярность различной аналитики, ботов и нейросетей. То есть, как ЯП для приложений он не будет популярен. Все остальное — поровну и по различным причинам, но не в серьез. То есть, если какая-то крутая компания имеет 98% кода на c# и потом говорит что что-то написала на go от скуки, то к сожалению, найдутся такие, которые трактуют это как — весь мир спешит перейти на go. И масла в огонь как всегда подольют школы, которые только и рады что у них появятся новые клиенты, которым они будут хелпы пересказывать.
Не понимаю очем вы… Я точно не из обиженных кем-то из перечисленных и не из самих перечисленных. Просто в последнее время очень часто слышу слово токсичность и не понимая его, пытался сам придумать ему определение. И вот раздумья меня подтолкнули к тому, что в любом случаи это те люди… Как бы сказать… Вот я однажды слышал выражение и оно лучше всего описывает этих людей. Оно говорит о том, что людям плохо не из-за того что корова сдохла, а что у соседа живая. Вот менгя такие недалекие люди просто не могут задеть. Даже злится на них и то сравнимо со злостью на детей. Они просто другие. Не в топку же их списывать.
Классификацию я тожелюблю, но класифицирую людей попризнакам причин, а не следствия и уже тем более не поведения, которое попросту мне не понятно.
Смотря что имеется ввиду под негативом. Судя по статье, для кого-то и чужая работа, обязывающая интересоваться успехами своих сотрудников, уже негатив. Для меня негатив, это когда чувак в своих бедах, за исключением редких случаев, винит кого-то другого. Вот такие чуваки, пока себя оправдывают, обрыжжят всех вокрук на милю. Этакая коричневая зона отчуждения, за которой, по их мнению, одни, фака, токсичные находятся.
Если говорить о верефикации водил\клиентов, то что это даст? В полиции и фсб, сотрудники проходят жесточайшую верификацию, но это не уберегает от взяточников, убийц, насильников и прочих негодяев. Какую верефикацию вы хотите для «бомбил»? Если говорить о верификации по следам в инете, то это ещё сомнительней. Так, в самом наяале, можно выявить только самых тупых, а вот самые опасные, как раз таки, будут сумеют создать о себе легенду.
Вы скорее всего хотите видеть в роли извозчика чуваков с высшим образованием и хорошими монерами на дорогих авто, при этом, работающих за копейки. Разве такое возможно?
А что с ci\cd? Travis бесплатный, вроде, только для опенсоурс проектов. Разве опенсорс проект может быть приватным? Если нет, то без Travis и смысла нет в приватных репозиториях.
Вас наверное удивит, но модульные окна, с точки зрения кода, это одна из самых сложных задач в написании интерфейсов. Более сложнее только задачи с драгом ограниченным какими-либо правилами.
Вы доказываете что в реакте можно передать ссылку на компонент, а не слот. Я говорю, что слот в 2019 году, в сознании разработчика, представляется реализацией на уровне шаблона. Контекст не предназначен для передачи компонентов, а фильтровать детей, чтобы вычлинить слоты, ну это позопрошлый век, это не декларативно, это сводит слова о преимуществах реакта на нет. И на данный момент с этим невозможно ничегоподелать. Нет внутренних механизмов, нет единства, сложно, а значит дорого поддерживать. Кроме того мало удовольстия тратить время на написание такого вот кода, когда его можно потратить на что-то другое.
Да, я был не прав. Просто если подумать, то говоря о современных ui компонентах и о декларативности, в голове рисуется шаблонный синтаксис представлений (html, jsx, шаблоны angular). И первое что нарисовалось в голове при ассоциации с slot в react, это render callback. На мой взгляд, по синтаксису он наиболее схож со slot в шаблонах. Передача компонента как props вообще не похожа на слоты в других инструментах. Но я сразу не подумал, что слотов может быть сколько угодно, а render callback, только один. Поэтому в реакт единственный вариант повторить функционал слотов, это props или render props. Но это не делает props или render prop слотом. Это просто передача компонента как пропса. Понятие слот тогда вообще не применимо к реакту.
И передав компонент как пропс, функционал получится тот же, но удовольствие уже испортится. На дворе 2019 год, и мне не хочется писать множество render props, превращая шаблон в кашу. Это жуткий минут реакта. Они всюду говорят что это только вью, но по сравнению с другими вьюхами, вью реакта прошлый век. Реакт не развивается как вью. Он все больше обрастает js'ом в шаблоне.
Слоты они и в вебкомпонентах, ангуляре и vue — слоты.
Согласен! Но Ваше представление о пользовательской логике слотов, отличается от реализвации пользовательской логики в описанных Вами же технологиях. В реакт, ближе всего по духу к слотам — render callback.
И почему декларативность нарушается?
Вам виднее…
И сравнивать юнит с интаграционными тестами и говорить что одни нужнее других, это свидетельство о нездоровом непонимании процесса разработки. Кроме того, DI и, в случаи с компонентами в качестве props, агрегация, это как небо и земля.
Поверьте на слово — да! Я слежу за развитием реакта, Дэна, соощества с самого их появления. Кроме того, с самого начала я был с ними вомного не согласен. Я основывался на swing, javafx, wpf, mobile, разработка uix для игровых приложений. А все сообщество опиралось лишь на мнение Дэна. И это происходит до сих пор. При чем, если даже не обращать внимание, как он мнение меняет, то все ещё остается актуальной тема, почему он так медленно развивается. Почему он, имеющий такое влияние, до сих пор не сделал из react инструмент для разработчиков?! На фоне других инструментов и технологий, react досих пор выглядит как плацдарм для эксперементов Дэна. И самое ужасное, что все во что может переасти ui, уже давно описано и вместо того, чтобы включить мозг, все сообщество, так и полагаются на Дэна. Зная Дена, могу с уверенность сказать, что он назвал бы это «глупое или stateless сообщество». Правильных, устаявшихся названий он либо не знает, либо маркетинг fb не позволяет. И видимо на большее фантазии не хватает как у него, так и всего отдела маркетинга.
И да, в статье неточность. Слоты (slot), это render callback, а не то что описано в статье. Кроме того, не могу не заметить, что продвигаемая «фишка» в виде rander callback, жутнко нарушает предыдущий столп маркетинга реакта — декларативность jsx.
И да, чтобы кому-то не показалось что я реакто и Дэно ненавистник, могу сказать, что я много лет пишу на реакте и несмотря на то, что ещё столько же лет пишу на angular и vue, бросать как его, так и другие инструменты не собираюсь. Будет скучно. Но не критиковать нельзя. Мне кажется, что это силаспособная подтолкнуть процес и сделать разработку ещё более драйвовым.
И Ваш пример с функцией просто идеально иллюстрирует то о чем я говорю. В то время как первый пример иллюстрирует иммутабельность.
представляющие название событий. Зачем придумывать все заного для js и ломать устоявшиеся каноны? Иммутабельность, это совсем не константы, это стиль\архитектура.
И да, бывает так сложно, что время затрачивается всотни раз больше. Например на js участок кода можно написать за минуту, а на ts день-два уйдет. Это при условии, что создаваемый код является описанием какого-то собственного архитектурного решения. То есть такая проработка очень редко требуется при работе с библиотеками или фраймворками. А вот при их написании она необходима. И с этим нужно смерится вне зависимости от потрачего времени. Ведь всем нравится умный автокомплит восста процентах работы с библиотекой. Ведь это экономит время и деньги и самое главное — нервы. Легче будет только если код будет писать ИИ.
И странное, что в 2019 году trypescript ещё не все используют. js, если будет долго жить, то станет ts.
Классификацию я тожелюблю, но класифицирую людей попризнакам причин, а не следствия и уже тем более не поведения, которое попросту мне не понятно.
Вы скорее всего хотите видеть в роли извозчика чуваков с высшим образованием и хорошими монерами на дорогих авто, при этом, работающих за копейки. Разве такое возможно?
И передав компонент как пропс, функционал получится тот же, но удовольствие уже испортится. На дворе 2019 год, и мне не хочется писать множество render props, превращая шаблон в кашу. Это жуткий минут реакта. Они всюду говорят что это только вью, но по сравнению с другими вьюхами, вью реакта прошлый век. Реакт не развивается как вью. Он все больше обрастает js'ом в шаблоне.
Согласен! Но Ваше представление о пользовательской логике слотов, отличается от реализвации пользовательской логики в описанных Вами же технологиях. В реакт, ближе всего по духу к слотам — render callback.
Вам виднее…
И сравнивать юнит с интаграционными тестами и говорить что одни нужнее других, это свидетельство о нездоровом непонимании процесса разработки. Кроме того, DI и, в случаи с компонентами в качестве props, агрегация, это как небо и земля.
И да, в статье неточность. Слоты (slot), это render callback, а не то что описано в статье. Кроме того, не могу не заметить, что продвигаемая «фишка» в виде rander callback, жутнко нарушает предыдущий столп маркетинга реакта — декларативность jsx.
И да, чтобы кому-то не показалось что я реакто и Дэно ненавистник, могу сказать, что я много лет пишу на реакте и несмотря на то, что ещё столько же лет пишу на angular и vue, бросать как его, так и другие инструменты не собираюсь. Будет скучно. Но не критиковать нельзя. Мне кажется, что это силаспособная подтолкнуть процес и сделать разработку ещё более драйвовым.