попсовый софт как яндекс диск(нет гуя для линукса), маил диск(нет даже консольного но можно накрасноглазить через rclone mount)
Это не проблема Linux (Ubuntu, Mint, и так далее), а проблема создателей данных приложений (Яндекс и Mail Group соответственно)...
Говоря другими словами, отсутствие того или иного "привычного Windows пользователю" приложения в том виде, с которым данный пользователь привык работать, не относится к проблемам или минусам Linux операционных систем.
К тому же, в последнее время, некоторые производители программного обеспечения начинают адаптировать или выпускать приложения, чтобы в том и или ином случае, у пользователя возникло меньше проблем с адаптацией к другой операционной системе.
Плохой пиар - тоже пиар )) Черный пиар - тоже пиар )) И тд ))
@nin-jinа можно уже перестать продвигать ваши решения, как единственно верные?.. Хотят использовать Moment.js (или любую другую библиотеку), то пусть используют, так как в большинстве своём это продиктовано руководством, или другой иной причиной ))
---------
По статье: большинство решений можно написать самому без использования каких-либо сторонних библиотек, что в некоторых случаях может снизить итоговый вес исполняемого файла, а также снизить риск в контексте "вдруг автор библиотеки сделает что-то неприятное" ))
Смотря на то, какой именно код вы используете в своём примере, сугубо по моему личному мнению, есть подозрение, что данный пример сильно "притянут за уши". И, на основе личного опыта, есть вопрос: а почему нельзя использовать useEffect на каждое из состояний в отдельности?
Пояснение вопроса: у нас есть несколько состояний нашего условного компонента, и каждое состояние, по написанной логике, отвечает за определенное поведение компонента, и мне не очень понятно, почему по одному изменению пропса должны меняться все состояния в совокупности разом, если каждое из данных состояний должно порождать то или иное дальнейшее поведение. То есть: category -> порождает обновление ссылки -> ссылка порождает fetch -> результат ответа (response / catch) на запрос порождает изменение либо data с обнулением error, либо error с обнулением data -> наличие которых уже порождает изменение isLoading, что в свою очередь позволяет держать актуальные состояния и ошибки в текущем моменте, а не держать их из "прошлого".
Попробуйте через голосового робота записаться на приём в поликлинику при дефектах речи (раза с тьсатого у вас получится, а при разговоре с оператором - с первого). И это полностью аналогично звонку в банк.
Ситуации бывают настолько разные, что шаблонов ответов и действий на них нет, из-за чего и необходима возможность связаться с оператором, который уже сможет, даже спустя некоторое время, найти решение, либо соединить с тем, у кого хватает квалификации и/или опыта в решении именно данной ситуации
И это касается, как голосовых, так и текстовых ботов/помощников, которые оперируют только шаблонами, и не подразумевают под собой воздействие человеческого фактора, как при получении той или иной услуги, так и при предоставлении услуги.
Поэтому, у всех ботов/помощников должна быть кнопка "связаться с оператором", либо "обратиться в поддержку"
PS: Всегда всё пытаются взвалить на сотрудников, при этом забывая, что сотрудник продуктивен в том случае, если для этого созданы все необходимые условия, о которых в своё время не одну статью здесь публиковали
PPS: ТОП-26 программ мониторинга тотального слежения для мнительных работодателей
Самая главная фича лично для меня это способность изменять пропсы компонента
Кто вам сказал, что менять props это замечательно и так нужно делать всегда? Вы не меняете props для компонента, к сожалению, вы меняете state, если судить по примеру, который вы привели.
Не знаю как вам, но в каждом проекте я сталкивался с необходимостью менять пропс
никогда с таким, лично, не сталкивался, сколько бы проектов не было за плечами.
И никакой тайпскрипт не нужен. Честно, ненавижу тайпскрипт.
TypeScript - не зло, которое нужно ненавидеть, но "на вкус и цвет..."
В реакте есть чудо юзэффект. У вью тоже есть computed, но почему то именно в моем коде мне приходилось всяческий изощряться чтобы заставить его работать.
Как это логично, не справились вы - но вините в этом инструмент. Это звучит так, "У меня не получилось забить гвоздь, виноват молоток" :)
If-elseIf-else, await, store, events
"Смешались в кучу кони, люди..." (с) М. Лермонтов. Бородино
На пункте "Special elements" я устал читать заметку автора о том, что "молоток не забивает винты, а отвертка не закручивает гвозди"... :)))
Это дело автора, его личное мнение и личная позиция, с которой спорить не буду, но дам один маленький, ничтожный совет: "Наполните заметку полноценными примерами как во Vue, так и на Svetle, чтобы у читателей была возможность в сравнение"
Сам по себе WebSocket никакого влияния не оказывает. Оказывает только умением им пользоваться для отображения данных, полученных, например, от сервера в момент опроса поисковыми ботами.
Профильные эксперты считают, что если доступ к реестру появится у всего кредитного рынка, то это может вызвать определённые сложности и риски, касающиеся утечки информации. По их мнению, при отказе в кредите правовые риски есть, но для банков они будут незначительными.
По порядку (сугубо моё личное мнение и видение данной ситуации):
Утечка информации всегда есть, даже на моменте создания реестра. Всегда стоит только вопрос в размере материального обеспечения к созданию данного риска - чем выше размер, тем выше шанс. И, какой бы закон, указ и/или постановление не вводилось для борьбы, то всегда будет тот/те, кто будет игнорировать данное ограничение, в особенности, учитывая размер штрафных выплат.
Правовые риски могут в дальнейшем сыграть обратную роль, и, вместо того, чтобы полностью оправдывать решение о непредоставлении услуги, они создают минимум один претендент на полное обжалование, что повлечет за собой:
Снижение доверия к государственным органам
Снижение доверия к банковской организации
и любые дальнейшие шаги, опирающиеся на данные выше пункты
Прежде, чем вводить что-то, принимать на том и/или ином уровне, необходимо продумать все возможные случаи, с которыми может столкнуться действие этого чего-то, а не "сначала вводим, разбираемся потом", как это делается последние n-десятков лет.
Скажу за свой опыт: мне попался очень хороший репетитор, который за месяц занятий обучил меня понимаю грамматики в сотни раз лучше, чем преподавали в школе )
Паттерн MVVM как раз и состоит из 3 частей (M - model, V - view, VM - view model), чего для самого паттерна достаточно, любые Binder, Controller и прочее - это уже дополнительные классы/модули, которые расширяют функционал MVVM.
Binder (биндер). Слой, помогающий связать вью и вью модель в автоматическом режиме. Почему-то совершенно игнорируется вики на русском языке, хотя, если верить английской версии сайта, это самый важный компонент паттерна, а сам паттерн можно называть model-view-binder.
Сам паттерн назвать Model-View-Binder? А смысл тогда использовать MVVM? Ответ весьма лаконичен: непонимание того, что есть Binder, не говорит о том, что мы используем другой паттерн, мы остаёмся также в пределах одного паттерна, только дополняем его функционал, делаем код более читаемым, разбиваем логику на части (легче исправлять небольшие файлы, чем один, но на "миллионы" строк)
---
В общем и целом, я согласен с @splatt, так как вы просто переписали Wikipedia, не понимая того, как это будет работать в отличных от ваших условиях и для чего это использовать.
Абстрактные примеры для того и абстрактные, что они дают самое поверхностное представление, но не заявляют, что так правильно и/или так надо делать всегда и везде.
Мне кажется, что лет так через десяток, выяснится, что исследования связи игр и насилия, были пролоббированы и подтасованы крупными разработчиками видеоигр, как было неоднократно в истории.
Лет через 10 будет другое поколение, и поколение от поколения меняется. И даже в каждом поколении есть индивидуумы, которые отличаются в обратную сторону.
Взаимосвязи шутеров и насилия среди гигантской части населения нет. А там, где это имеет место быть, то связь выявляется в другом: отношение сверстников, родных и не родных, восприятии мира и психических отклонениях самого человека. Что было не одну тысячу раз доказано, иначе, все геймеры - убийцы, насильники и маньяки.... )
Тот момент, когда старая обложка выглядит куда приятней новой. И дело даже не в количестве, а в том, как они подобраны.
Если сравнивать с обложкой нового Cosmo, то старый выглядит лаконично и понятны акценты, при этом на новом - мы накидали разные шрифты и их вариации (словно в "голове у блондинки" - всё в одном месте и сразу), но при этом, менее разнообразное оформление будет уже внутри самого журнала, если рассматривать его не как единый набор текста, а как отдельные статьи и/или секции.
В этом и заключается основное отличие: в давние времена ограничение шрифтов в обложке (буклете, рекламе, брошюре и тд) было связано с тем, чтобы доставить информацию конечному пользователю, при этом, в текущее время, продать (выделить) бренд на фоне других подобных.
Именно "продажа" и есть основная причина, а не обоснованность.
В рамках одной статьи шрифт используют по правилу, о котором говорят вам "столпы"
Шрифтовая пара — это два шрифта, которые используют в дизайне для оформления текстов на одном пространстве
Говоря другими словами, в каждом пространстве (блоке) вы можете использовать другие шрифты с целью привлечения внимания пользователя к той или иной поднимаемом в блоке теме, либо отсечению одного блока от другого.
Маленький пример: У вас может быть два шрифта для одной статьи (заголовок и основной текст), но для блока цитат вы можете использовать совершенно другой, а для рекламы - и вовсе ещё 2 дополнительных шрифта.
Вы в праве использовать любое количество шрифтов, если у этого решения есть обоснование. Ограничений к этому больше нет.
И, в общем ключе, я согласен с тем, что использовать можно любое количество шрифтов, но, главное не обоснованность, а результат достижения цели (привлечь, удержать, "продать" и тд)
Скачиваете архив с github и распаковываете его, затем переходите в "Меню браузера" --> "Дополнительные инструменты" --> "Расширения", там включаете "Режим разработчика", жмете на кнопку "Загрузить распакованное расширение", загружаете и можно пользоваться.
Отлично, а можно тоже самое, только в внутри статьи? ))
Успею, так как не буду ехать 60 км/ч за 10 метров до пешеходного, а буду ехать 30-35 км/ч (если в радиусе 5 метров от пешеходного нет людей) или менее 20 км/ч (если есть люди).
Это не проблема Linux (Ubuntu, Mint, и так далее), а проблема создателей данных приложений (Яндекс и Mail Group соответственно)...
Говоря другими словами, отсутствие того или иного "привычного Windows пользователю" приложения в том виде, с которым данный пользователь привык работать, не относится к проблемам или минусам Linux операционных систем.
К тому же, в последнее время, некоторые производители программного обеспечения начинают адаптировать или выпускать приложения, чтобы в том и или ином случае, у пользователя возникло меньше проблем с адаптацией к другой операционной системе.
Плохой пиар - тоже пиар ))
Черный пиар - тоже пиар ))
И тд ))
@nin-jinа можно уже перестать продвигать ваши решения, как единственно верные?.. Хотят использовать Moment.js (или любую другую библиотеку), то пусть используют, так как в большинстве своём это продиктовано руководством, или другой иной причиной ))
---------
По статье: большинство решений можно написать самому без использования каких-либо сторонних библиотек, что в некоторых случаях может снизить итоговый вес исполняемого файла, а также снизить риск в контексте "вдруг автор библиотеки сделает что-то неприятное" ))
Спасибо за пример, и небольшое пояснение.
Смотря на то, какой именно код вы используете в своём примере, сугубо по моему личному мнению, есть подозрение, что данный пример сильно "притянут за уши". И, на основе личного опыта, есть вопрос: а почему нельзя использовать useEffect на каждое из состояний в отдельности?
Пояснение вопроса: у нас есть несколько состояний нашего условного компонента, и каждое состояние, по написанной логике, отвечает за определенное поведение компонента, и мне не очень понятно, почему по одному изменению пропса должны меняться все состояния в совокупности разом, если каждое из данных состояний должно порождать то или иное дальнейшее поведение. То есть: category -> порождает обновление ссылки -> ссылка порождает fetch -> результат ответа (response / catch) на запрос порождает изменение либо data с обнулением error, либо error с обнулением data -> наличие которых уже порождает изменение isLoading, что в свою очередь позволяет держать актуальные состояния и ошибки в текущем моменте, а не держать их из "прошлого".
ну как бы: https://learn.javascript.ru/import-export#dovod-protiv-eksportov-po-umolchaniyu
Попробуйте через голосового робота записаться на приём в поликлинику при дефектах речи (раза с тьсатого у вас получится, а при разговоре с оператором - с первого). И это полностью аналогично звонку в банк.
Ситуации бывают настолько разные, что шаблонов ответов и действий на них нет, из-за чего и необходима возможность связаться с оператором, который уже сможет, даже спустя некоторое время, найти решение, либо соединить с тем, у кого хватает квалификации и/или опыта в решении именно данной ситуации
И это касается, как голосовых, так и текстовых ботов/помощников, которые оперируют только шаблонами, и не подразумевают под собой воздействие человеческого фактора, как при получении той или иной услуги, так и при предоставлении услуги.
Поэтому, у всех ботов/помощников должна быть кнопка "связаться с оператором", либо "обратиться в поддержку"
Не появится эта кнопка, у всех "топ-менеджеров" только "экономия" пополнения кармана )
...
PS: Всегда всё пытаются взвалить на сотрудников, при этом забывая, что сотрудник продуктивен в том случае, если для этого созданы все необходимые условия, о которых в своё время не одну статью здесь публиковали
PPS: ТОП-26 программ
мониторингатотального слежения для мнительных работодателейКто вам сказал, что менять
propsэто замечательно и так нужно делать всегда? Вы не меняетеpropsдля компонента, к сожалению, вы меняетеstate, если судить по примеру, который вы привели.никогда с таким, лично, не сталкивался, сколько бы проектов не было за плечами.
TypeScript- не зло, которое нужноненавидеть, но "на вкус и цвет..."Как это логично, не справились вы - но вините в этом инструмент. Это звучит так, "У меня не получилось забить гвоздь, виноват молоток" :)
"Смешались в кучу кони, люди..." (с) М. Лермонтов. Бородино
На пункте "Special elements" я устал читать заметку автора о том, что "молоток не забивает винты, а отвертка не закручивает гвозди"... :)))
Это дело автора, его личное мнение и личная позиция, с которой спорить не буду, но дам один маленький, ничтожный совет: "Наполните заметку полноценными примерами как во Vue, так и на Svetle, чтобы у читателей была возможность в сравнение"
Сам по себе WebSocket никакого влияния не оказывает. Оказывает только умением им пользоваться для отображения данных, полученных, например, от сервера в момент опроса поисковыми ботами.
Никак. Они реагируют только на данные/контент.
Рекомендую к ознакомлению, с примерами, интерактивными решениями.
По порядку (сугубо моё личное мнение и видение данной ситуации):
Утечка информации всегда есть, даже на моменте создания реестра. Всегда стоит только вопрос в размере материального обеспечения к созданию данного риска - чем выше размер, тем выше шанс. И, какой бы закон, указ и/или постановление не вводилось для борьбы, то всегда будет тот/те, кто будет игнорировать данное ограничение, в особенности, учитывая размер штрафных выплат.
Правовые риски могут в дальнейшем сыграть обратную роль, и, вместо того, чтобы полностью оправдывать решение о непредоставлении услуги, они создают минимум один претендент на полное обжалование, что повлечет за собой:
Снижение доверия к государственным органам
Снижение доверия к банковской организации
и любые дальнейшие шаги, опирающиеся на данные выше пункты
Прежде, чем вводить что-то, принимать на том и/или ином уровне, необходимо продумать все возможные случаи, с которыми может столкнуться действие этого чего-то, а не "сначала вводим, разбираемся потом", как это делается последние n-десятков лет.
Скажу за свой опыт: мне попался очень хороший репетитор, который за месяц занятий обучил меня понимаю грамматики в сотни раз лучше, чем преподавали в школе )
Паттерн MVVM как раз и состоит из 3 частей (M - model, V - view, VM - view model), чего для самого паттерна достаточно, любые Binder, Controller и прочее - это уже дополнительные классы/модули, которые расширяют функционал MVVM.
Сам паттерн назвать Model-View-Binder? А смысл тогда использовать MVVM? Ответ весьма лаконичен: непонимание того, что есть Binder, не говорит о том, что мы используем другой паттерн, мы остаёмся также в пределах одного паттерна, только дополняем его функционал, делаем код более читаемым, разбиваем логику на части (легче исправлять небольшие файлы, чем один, но на "миллионы" строк)
---
В общем и целом, я согласен с @splatt, так как вы просто переписали Wikipedia, не понимая того, как это будет работать в отличных от ваших условиях и для чего это использовать.
Абстрактные примеры для того и абстрактные, что они дают самое поверхностное представление, но не заявляют, что так правильно и/или так надо делать всегда и везде.
Лет через 10 будет другое поколение, и поколение от поколения меняется. И даже в каждом поколении есть индивидуумы, которые отличаются в обратную сторону.
Взаимосвязи шутеров и насилия среди гигантской части населения нет. А там, где это имеет место быть, то связь выявляется в другом: отношение сверстников, родных и не родных, восприятии мира и психических отклонениях самого человека. Что было не одну тысячу раз доказано, иначе, все геймеры - убийцы, насильники и маньяки.... )
Тот момент, когда старая обложка выглядит куда приятней новой. И дело даже не в количестве, а в том, как они подобраны.
Если сравнивать с обложкой нового Cosmo, то старый выглядит лаконично и понятны акценты, при этом на новом - мы накидали разные шрифты и их вариации (словно в "голове у блондинки" - всё в одном месте и сразу), но при этом, менее разнообразное оформление будет уже внутри самого журнала, если рассматривать его не как единый набор текста, а как отдельные статьи и/или секции.
В этом и заключается основное отличие: в давние времена ограничение шрифтов в обложке (буклете, рекламе, брошюре и тд) было связано с тем, чтобы доставить информацию конечному пользователю, при этом, в текущее время, продать (выделить) бренд на фоне других подобных.
Именно "продажа" и есть основная причина, а не обоснованность.
В рамках одной статьи шрифт используют по правилу, о котором говорят вам "столпы"
Говоря другими словами, в каждом пространстве (блоке) вы можете использовать другие шрифты с целью привлечения внимания пользователя к той или иной поднимаемом в блоке теме, либо отсечению одного блока от другого.
Маленький пример: У вас может быть два шрифта для одной статьи (заголовок и основной текст), но для блока цитат вы можете использовать совершенно другой, а для рекламы - и вовсе ещё 2 дополнительных шрифта.
И, в общем ключе, я согласен с тем, что использовать можно любое количество шрифтов, но, главное не обоснованность, а результат достижения цели (привлечь, удержать, "продать" и тд)
вижу минус за jquery, поставил бы минус минусу ?
Отлично, а можно тоже самое, только в внутри статьи? ))
Успею, так как не буду ехать 60 км/ч за 10 метров до пешеходного, а буду ехать 30-35 км/ч (если в радиусе 5 метров от пешеходного нет людей) или менее 20 км/ч (если есть люди).
ну почему же клевета? как раз-таки наоборот, более правдивое положение дел фреймворка
Да этого не будет. Проект $mol выглядит интересно, но подвержен правилу "идея отличная, реализация - как всегда"