И там кстати он акцентирует внимание на том, что это одна из ключевых особенностей, но не единственная. Тем самым оставляя пространство для маневров и существования иных мнений. Я считаю что при взаимодействии в команде желательно иметь рядом тех людей у которых почитаемые авторитеты в мире разработки ПО по большей части совпадают с вашими. Это разрешает многие вопросы о code style, паттернах, best practices и т.д.
Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.
Вообще в IT очень много сложных вещей, которым тяжело дать однозначное определение. Тот же паттерн MVC: одна и та же схема взаимодайствия компонентов у Майкрософт называется MVP, однако Эппл считает тоже самое истинным MVC. Нам остается лишь принимать сторону того, кого считаем авторитетом в исследуемом вопросе. Главное не устраивать крестовых походов)
Это вроде как стандартная практика. У w3school например эта услуга платная.
Сейчас посмотрел в интернете и не нашел бумажного варианта этого документа. Видимо в этом пункте я ошибся. Признаю.
Если сущность выглядит как утка, крякает как утка и летает как утка, то очевидно что это утка)
Я не верю в добрых самаритян, которые бесплатно тратят свое время на обучение новичков.
Qui prodest?
Не совсем. Callback можно передать методу библиотеки, но мы сами решаем когда вызывать этот метод. Например объект XMLHttpReques. Пока мы явно не сделаем ajax запрос, переданный в него callback будет висеть и ждать внутри свойства этого объекта. В случае с фреймворком, он сам решает что и когда должно произойти, следуя своей внутренней логике. Нам остается лишь предоставить колбэки и ждать пока система их сама вызовет.
Да и первоначальный вопрос был больше о React, который очевидно не библиотека, в классическом смысле этого слова, и явно не просто view. Однако многие люди склонны верить тому что написано, а не тому что видят.
О тонкостях в настраивании фреймворков внутри main судить не берусь, ибо не совсем понял как это должно работать)
Это связано со внутренними свойствами переменной. В целом это практически бесполезное знание, просто интересен ход мысли)
А второй вопрос не вызвал сложностей? В интернете в различных туториалах оно показано в упрощенном виде, что в определенных ситуациях вызывает ошибки (возможно встречали сайты, у которых пункты меню иногда не реагируют на нажатие)
Авторы этого списка вопросов — freeCodeCamp. Занимаются обучением новичков за донат и продажей бумажных сертификатов. Естественно в их интересах составить этот список таким образом, чтобы ученики не расслаблялись и конвертировались на платные курсы к менторам из ближнего круга. Типичный инфобизнес, короче)
Когда я ищу себе человека, я задаю ему лишь 3 вопроса:
1) Почему значение вновь созданной переменной равно undefined? (теория)
2) Как написать делегирование обработки клика на кнопке для структуры элементов типа ul > li > button > «some content» (практика)
3) React это библиотека или фреймворк? Почему так, а не иначе? (критическое мышление)
Потом слушаю ответы и наблюдаю ход мысли. В целом этого достаточно, чтобы составить первичное мнение о человеке. Все остальное покажет практика.
Сомнительное решение назначать font-size: 15px и line-height: 20px;
Если уж делать все по фэн-шую, то можно взять за правило, чтобы разница между высотой линии и высотой шрифта была четной: например font-size: 16px и line-height: 20px. Таким образом можно избежать проблем с полу-пикселями.
Второй момент: задавать фиксированную высоту кнопкам мне кажется плохой практикой. Пусть лучше она подстраивается под размер контента (высота линии + паддинг), ну или использовать свойство min-height по крайней мере.
Вместо media (hover) который судя по MDN не поддерживается в стандартном браузере Android можно использовать min-device-width: 1280px, который применяет ховер к большей части десктопных браузеров (хотя теперь он помечен как deprecated). Либо сочетать эти два способа вместе.
Ну и забыли классику упомянуть: touch-action: manipulation (убирает задержку в 300ms на мобильных браузерах при таче)
Люди придумали фреймворки, чтобы установить систему общих правил и подходов при разработке. Это должно было помочь исключить разногласия по вопросам архитектуры и создать некий свой мини-стандарт типа: «вью пишем через модули с таким вот интерфейсом, контроллер/обсервер/медиатор у нас реагирует вот на эти эвенты, модели взаимодействуют с вью посредством колбэков, а шаблонизатор у нас будет вот такой».
Все это прекрасно работает пока в отрасли существует 1-3 авторитетных фреймворка и программисты могут формировать довольно крупные сообщества приверженцев того или иного подхода, но когда количество фреймворков и их сочетаний с прочими инструментами разрастается до нескольких десятков, то это становится равносильно отсутствию каких либо стандартов.
React, Angular, Backbone, Ember, Extjs и т.д.
Добавьте сюда еще различные инструменты сборки и языки, компилируемые в JS.
Черт, когда я встречаю фронтендера, то мне неочем с ним говорить — его стек инструментов и технологий настолько далек от того что мне знакомо и понятно))
Я бы сравнил туториалы и множество книг — с инструкциями по строительству дома.
Информации о строительстве стен, кровле и прочим штукатурным работам в избытке, но вот как правильно заливать фундамент и готовить почву под него — практически нет инфы.
Паттерны проектирования описаны, но мало уделено внимания тому, когда и какой надо использовать. Про юнит тесты написано много книг, но как писать тестирумый код — снова умалчивается.
Самый короткий и наглядный пример этого безобразия запомнился мне из одной книги по js:
«Оператор delete используется когда вам надо удалить свойство из объекта»
И ни слова о том, зачем и для чего это применяется))
С курсами тоже самое — «мы учим синтаксису и фреймворкам — копипастите код очередного todo-app, улыбайтесь и ставьте лайки».
А чем написание кода на бумажке отличается от написания в IDE?
Если условились не придираться к синтаксису, то и разницы нет никакой получается. Что на бумаге пишем логику на псевдоязыке, что в компьютерной программе пишем эту же логику, но только с подсказками от компьютера по синтаксису (который мы в расчет не берем и так)
А почему нельзя сделать все тоже самое, но на виджетах, внедренных в стандартный html?
Пусть страницы останутся нативно-индексируемыми, а все что требует сложной интерактивности будет внутри неких компонентов. Я возлагал надежды на web-components в этом плане, но как то у них медленно все продвигается.
Подход верный, но применим лишь в случае работы на себя самого, где самостоятельно выбираешь технологический стек. Если намереваешься работать на дядю, то придется все свободное время тратить на изучение новомодных фреймворков, чтобы соответствовать требованиям работодателя. Это и есть причина, побуждающая программистов участвовать в этой бесконечной и изматывающей гонке)
Вообще в IT очень много сложных вещей, которым тяжело дать однозначное определение. Тот же паттерн MVC: одна и та же схема взаимодайствия компонентов у Майкрософт называется MVP, однако Эппл считает тоже самое истинным MVC. Нам остается лишь принимать сторону того, кого считаем авторитетом в исследуемом вопросе. Главное не устраивать крестовых походов)
Сейчас посмотрел в интернете и не нашел бумажного варианта этого документа. Видимо в этом пункте я ошибся. Признаю.
Я не верю в добрых самаритян, которые бесплатно тратят свое время на обучение новичков.
Qui prodest?
Да и первоначальный вопрос был больше о React, который очевидно не библиотека, в классическом смысле этого слова, и явно не просто view. Однако многие люди склонны верить тому что написано, а не тому что видят.
О тонкостях в настраивании фреймворков внутри main судить не берусь, ибо не совсем понял как это должно работать)
А второй вопрос не вызвал сложностей? В интернете в различных туториалах оно показано в упрощенном виде, что в определенных ситуациях вызывает ошибки (возможно встречали сайты, у которых пункты меню иногда не реагируют на нажатие)
1) Почему значение вновь созданной переменной равно undefined? (теория)
2) Как написать делегирование обработки клика на кнопке для структуры элементов типа ul > li > button > «some content» (практика)
3) React это библиотека или фреймворк? Почему так, а не иначе? (критическое мышление)
Потом слушаю ответы и наблюдаю ход мысли. В целом этого достаточно, чтобы составить первичное мнение о человеке. Все остальное покажет практика.
PS:
Писать код на бумажке не заставляю)
Ну типа все знает и все умеет, как передовик производства в СССР)
Сомнительное решение назначать font-size: 15px и line-height: 20px;
Если уж делать все по фэн-шую, то можно взять за правило, чтобы разница между высотой линии и высотой шрифта была четной: например font-size: 16px и line-height: 20px. Таким образом можно избежать проблем с полу-пикселями.
Второй момент: задавать фиксированную высоту кнопкам мне кажется плохой практикой. Пусть лучше она подстраивается под размер контента (высота линии + паддинг), ну или использовать свойство min-height по крайней мере.
Вспомнил assembler и вирус на байткоде, размером в 21 байт.
Ну и забыли классику упомянуть: touch-action: manipulation (убирает задержку в 300ms на мобильных браузерах при таче)
Все это прекрасно работает пока в отрасли существует 1-3 авторитетных фреймворка и программисты могут формировать довольно крупные сообщества приверженцев того или иного подхода, но когда количество фреймворков и их сочетаний с прочими инструментами разрастается до нескольких десятков, то это становится равносильно отсутствию каких либо стандартов.
React, Angular, Backbone, Ember, Extjs и т.д.
Добавьте сюда еще различные инструменты сборки и языки, компилируемые в JS.
Черт, когда я встречаю фронтендера, то мне неочем с ним говорить — его стек инструментов и технологий настолько далек от того что мне знакомо и понятно))
Информации о строительстве стен, кровле и прочим штукатурным работам в избытке, но вот как правильно заливать фундамент и готовить почву под него — практически нет инфы.
Паттерны проектирования описаны, но мало уделено внимания тому, когда и какой надо использовать. Про юнит тесты написано много книг, но как писать тестирумый код — снова умалчивается.
Самый короткий и наглядный пример этого безобразия запомнился мне из одной книги по js:
«Оператор delete используется когда вам надо удалить свойство из объекта»
И ни слова о том, зачем и для чего это применяется))
С курсами тоже самое — «мы учим синтаксису и фреймворкам — копипастите код очередного todo-app, улыбайтесь и ставьте лайки».
Печально все это ((
Если условились не придираться к синтаксису, то и разницы нет никакой получается. Что на бумаге пишем логику на псевдоязыке, что в компьютерной программе пишем эту же логику, но только с подсказками от компьютера по синтаксису (который мы в расчет не берем и так)
Пусть страницы останутся нативно-индексируемыми, а все что требует сложной интерактивности будет внутри неких компонентов. Я возлагал надежды на web-components в этом плане, но как то у них медленно все продвигается.