Вместо того чтобы управлять API для вашей базы данных и бизнес-логики в другом месте, мы позволяем вам делать это непосредственно внутри ваших компонентов, именно там, где они нужны.
Десятилетия мы шли к инкапсуляции логики и структурному разделению модели и представления. Неужели мы были неправы?)
Вы правы в том, что здесь не используется принцип десятичных разрядов. Однако другая разрядность всё же присутствует: https://habr.com/ru/articles/149791/
Как лихо некоторые бесполезные и, как минимум, спорные особенности представлены в статье как преимущества библиотеки.
Новая либа фигачит всё в единый файл? И теперь все ваши хот-релоады и FCP (First Contentful Paint) идут по одному месту? Это никакая не недоработка, как вы по неопытности могли подумать! Это перфоманс и решение проблем с рантаймом!
Либа применяет последние стили, словно к ним подписаны «!important»? И теперь цвета для ваших иконок вы обязаны передавать внутрь компонента иконок и возможности управления цветом из родителя у вас больше нет? Что за дичь, могли бы вы сказать! Но нет, это называется предсказуемость!
В общем дальше лень писать. Не буду говорить что либа отстой и полная фигня, но выглядит она так, будто создается строго под какой-то определенный воркфлоу и вряд ли будет давать хоть какую-то пользу тем, у кого он отличается.
Про общественное мнение: его действительно не должно волновать ничье мнение, он будет жить и считать себя Вами, имея Вашу память. С этим никто не спорит.
Про Ваше согласие на своё уничтожение: при этом вы должны понимать, что именно для Вас никакого продолжения не будет. Вас после уничтожения ждёт лишь темнота (не берем сейчас религиозные взгляды во внимание, дабы не усложнять). Но для другого Вас, нового, само собой, всё продолжится, и он будет считать себя Вами, просто в новом теле.
Про две идентичные личности: мой пример из комментария выше был написан как раз для того, чтобы показать, что по итогу мы получим две, хоть и одинаковые, личности, а не одну в новом теле. То есть у нас по итогу эксперимента будет два человека. Проблемы здесь действительно нет, но я расписывал идею именно для того, чтобы показать то, о чем Вы написали в двух последних абзацах. А именно о том, что при копировании мы получим двух людей. У каждого из которых должен быть страх смерти и желание жить.
В итоге, из Ваших ответов, я понял, что Вы, как и я, считаете, что при процессе копирования образуется две личности (пусть и одинаковые). Но при этом Вы готовы стереть себя, оставив взамен копию (предположим, что она в чем-то лучше, например - новое тело) и вполне понимая что это будет для Вас смертью.
Но я мог не правильно Вас понять. Прошу прощения, если так.
В том-то и дело, что так считать будет ОН. Это его сознание будет иметь твою память, но при этом именно ты написал комментарий, не он. Чтобы моя мысль стала более понятной, приведу для примера воображаемую ситуацию:
Учёные научились телепортировать человека путём полного информационного сканирования и сборки на другой стороне из атомов по этому информационному образу. Уснувший подопытный, которого только что скопировали, и который, по задумке учёных, должен был исчезнуть, из-за какого-то технического сбоя не распался на атомы, а проснулся и вышел из капсулы сканирования целым и невредимым. В то же время из другой капсулы вышла полная копия скопированного человека. Ученые всполошились, бегают вокруг обоих, задают вопросы, проводят тесты. После чего приходят к выводу, что это два полностью идентичных организма с одинаковым мышлением и реакциями.
Внимание, вопрос! Кого из них учёные должны умертвить и распылить на атомы, чтобы опыт телепортации считался успешным? И согласиться ли первый, оригинальный подопытный, что от него надо избавиться, ибо так и предполагалось изначально?
Скажет ли второй первому, что теперь именно он является тем человеком, которым был первый до сих пор? Ведь субъективно он уснул и проснулся, просто в другом месте. А первый является ошибкой, не стёртым мусором.
Как выше написали, зависит от объема функциональности, которую хочется перетащить на vue. Но в любом случае упростится поддержка, если знаком с фреймворком
Почти со всем согласен, кроме высказывания про vuex и god-object'ы на 100500 полей) Если правильно разбивать функциональность приложения, то таких объектов не будет. Можно подумать, что при разбитии может критично увеличиться количество связей, но это как раз происходит из-за неправильного определения границ этой функциональности (либо неправильно реализованного общения между частями приложения).
Однако, если god-object'ы действительно нравятся, то на**кодить их легче лёгкого: vuex, с виду, прям сам подталкивает к их написанию)) Так что тут вы тоже частично правы)
Десятилетия мы шли к инкапсуляции логики и структурному разделению модели и представления. Неужели мы были неправы?)
Кто последний? За кем занимать?
Понял, спасибо, буду знать!
Вы правы в том, что здесь не используется принцип десятичных разрядов. Однако другая разрядность всё же присутствует: https://habr.com/ru/articles/149791/
CSS-in-JS имеет свои приемущества, но думаю, многие согласятся, удобство разработчика не в этом списке)
Как лихо некоторые бесполезные и, как минимум, спорные особенности представлены в статье как преимущества библиотеки.
Новая либа фигачит всё в единый файл? И теперь все ваши хот-релоады и FCP (First Contentful Paint) идут по одному месту? Это никакая не недоработка, как вы по неопытности могли подумать! Это перфоманс и решение проблем с рантаймом!
Либа применяет последние стили, словно к ним подписаны «!important»? И теперь цвета для ваших иконок вы обязаны передавать внутрь компонента иконок и возможности управления цветом из родителя у вас больше нет? Что за дичь, могли бы вы сказать! Но нет, это называется предсказуемость!
В общем дальше лень писать. Не буду говорить что либа отстой и полная фигня, но выглядит она так, будто создается строго под какой-то определенный воркфлоу и вряд ли будет давать хоть какую-то пользу тем, у кого он отличается.
Не совсем так, ведь есть так называемая «специфичность», и обращение в css через 11 вложенных классов перебьет обращение по id.
Но это надо очень сильно постараться (читать как «наверти**ячить»), чтобы встретить такой кейс в реальной разработке.
Ого! Фэйсбук придумали свой styled-components, только с нотацией покорявее, и с пока что неизвестными приемуществами.
Ну, молодцы, что тут ещё сказать...
Там ещё третий проглядывает:
Круто, что на реакте, жаль, что не на реакт‑нэйтиве
Но обязательно исключить некруглые муровейники и отбросить муровейники, расположивщиеся у дерева
Теперь понял Вашу точку зрения и предпосылки для первого комментария.
Спасибо за беседу! Было приятно пообщаться)
Про общественное мнение: его действительно не должно волновать ничье мнение, он будет жить и считать себя Вами, имея Вашу память. С этим никто не спорит.
Про Ваше согласие на своё уничтожение: при этом вы должны понимать, что именно для Вас никакого продолжения не будет. Вас после уничтожения ждёт лишь темнота (не берем сейчас религиозные взгляды во внимание, дабы не усложнять). Но для другого Вас, нового, само собой, всё продолжится, и он будет считать себя Вами, просто в новом теле.
Про две идентичные личности: мой пример из комментария выше был написан как раз для того, чтобы показать, что по итогу мы получим две, хоть и одинаковые, личности, а не одну в новом теле. То есть у нас по итогу эксперимента будет два человека. Проблемы здесь действительно нет, но я расписывал идею именно для того, чтобы показать то, о чем Вы написали в двух последних абзацах. А именно о том, что при копировании мы получим двух людей. У каждого из которых должен быть страх смерти и желание жить.
В итоге, из Ваших ответов, я понял, что Вы, как и я, считаете, что при процессе копирования образуется две личности (пусть и одинаковые). Но при этом Вы готовы стереть себя, оставив взамен копию (предположим, что она в чем-то лучше, например - новое тело) и вполне понимая что это будет для Вас смертью.
Но я мог не правильно Вас понять. Прошу прощения, если так.
В том-то и дело, что так считать будет ОН. Это его сознание будет иметь твою память, но при этом именно ты написал комментарий, не он. Чтобы моя мысль стала более понятной, приведу для примера воображаемую ситуацию:
Учёные научились телепортировать человека путём полного информационного сканирования и сборки на другой стороне из атомов по этому информационному образу.
Уснувший подопытный, которого только что скопировали, и который, по задумке учёных, должен был исчезнуть, из-за какого-то технического сбоя не распался на атомы, а проснулся и вышел из капсулы сканирования целым и невредимым. В то же время из другой капсулы вышла полная копия скопированного человека.
Ученые всполошились, бегают вокруг обоих, задают вопросы, проводят тесты. После чего приходят к выводу, что это два полностью идентичных организма с одинаковым мышлением и реакциями.
Внимание, вопрос!
Кого из них учёные должны умертвить и распылить на атомы, чтобы опыт телепортации считался успешным?
И согласиться ли первый, оригинальный подопытный, что от него надо избавиться, ибо так и предполагалось изначально?
Скажет ли второй первому, что теперь именно он является тем человеком, которым был первый до сих пор? Ведь субъективно он уснул и проснулся, просто в другом месте. А первый является ошибкой, не стёртым мусором.
Надеюсь я смог донести свою мысль.
Субъективно восприниматься так будет им, а не тобой. К сожалению, ты будешь мертв.
Увы, тут самоидентификация будет работать лишь в одну сторону: он является тобой, но ты не являешься им.
Тоже самое будет ровно до момента переноса элемента на следующую строку. И вот там уже будет отличие между 1 и 0.5
Что-то это начинает очень походить на akket.com. Даже обидно как-то за хабр.
Как выше написали, зависит от объема функциональности, которую хочется перетащить на vue. Но в любом случае упростится поддержка, если знаком с фреймворком
При понимании фреймворка выйгрыш в поддержке всё же будет
Почти со всем согласен, кроме высказывания про vuex и god-object'ы на 100500 полей) Если правильно разбивать функциональность приложения, то таких объектов не будет. Можно подумать, что при разбитии может критично увеличиться количество связей, но это как раз происходит из-за неправильного определения границ этой функциональности (либо неправильно реализованного общения между частями приложения).
Однако, если god-object'ы действительно нравятся, то на**кодить их легче лёгкого: vuex, с виду, прям сам подталкивает к их написанию)) Так что тут вы тоже частично правы)