Я планирую попробовать записывать свои ежедневные инсайты, интересные библиотеки, интересные статьи, интересные вещи и мысли. Пройдите весь путь и оставьте несколько следов.
О чтении исходного кода
Это интервью было немного натянутым. Многие компании зададут вам этот вопрос: вы читали исходный код React? Ответ: не читал. Сразу же я почувствовал, как часть моей уверенности в себе упала. В Интернете также есть различные статьи и интенсивы по анализу исходного кода, но у меня все еще не хватает смелости и интереса читать исходный код такой зрелой библиотеки, и даже если я хочу ее читать, я не не знаю с чего начать.
Но для интервью, похоже, что это требуется?
Поэтому я побежал на Reddit и разместилодна наклейка, хотелось бы спросить, что думают по этому поводу иностранцы.
Через десять минут я получил ответ, полный текст которого выглядит следующим образом:
But I can't bring myself on reading the source code of such a mature project, I don't even know where to begin.
Don't feel bad. I think every one of us on the core team has parts of React that we have not read (or at least are only vaguely familiar with).
So I wonder, especially for those who've read the code, is it important to read the source code if you are searching for a senior job?
My feeling is a strong "no" for this one. You don't need to read the source code to use React effectively. The docs should be sufficient! If they aren't, we've done a poor job.
Простой перевод выглядит следующим образом:
Я не могу прочитать исходный код и не знаю, с чего начать
Не расстраивайтесь, у всех в нашей основной команде разработчиков React есть более или менее часть исходного кода, которая не была прочитана.
Я хочу спросить людей, которые читали его, нужно ли читать исходный код, чтобы найти старшую работу?
Лично я твердо чувствую "Нет". Используйте React эффективно, не читая исходный код. Официальной документации должно быть достаточно! Если этого недостаточно, значит, наша работа сделана некачественно.
Ха-ха, не удивительно, не удивительно. Отправляйтесь в Tieba и наткнитесь на боссов Facebook. Босс сделал заявление, и, по оценкам, все, кто должен был его прочитать, также отступили. Очень жаль не услышать негативный голос, конечно, это лучше, чем удивление от такого ответа.
Личное мнение такое:
- Поймите жизненный цикл
- Понимание алгоритма diff (сверки документации)
Даже если React — это черный ящик, знание правил, по которым он работает, может ответить на множество вопросов «это не влияет на производительность».
Второй ответ, acemarke, мейнтейнер документации по редуксу, всегда охотно отвечает на разные вопросы, сказал, что не читал исходный код, что меня удивило. В то же время я решил пока не читать ее. В конце концов, так много нужно сделать и так многому научиться. Скорость обновления на передней панели безумна. Пусть к черту интервью (шутка).
вопрос
- Какова алгоритмическая сложность diff?
- Если ключи двух подэлементов одинаковы, что будет делать алгоритм сравнения React (ключ нельзя использовать, чтобы отличить, что есть что)?
Первая проблема — O(n).Что касается второго вопроса, всех, кто знает ответ, убедительно просим оставить сообщение.:D
Дополнение: Взял несколько демок и протестировал.Результаты рендеринга очень нестабильны при одинаковых ключах.Простейший массив сопоставляется сdivВроде рендерится нормально, но тест todolist обнаружил, что пока есть дублирующиеся ключи, будет рендериться только первый. Интересно, что даже текст предупреждения в некоторых случаях немного отличается (это может быть вызвано и разными версиями реакции), но общий смысл таков: повторяющиеся ключи вызовут неизвестные ситуации, а рендеринг элементов с повторяющимися ключами может быть проигнорирован, Дублирование также возможно. Здесь действительно стоит взглянуть на исходный код, чтобы узнать, как происходит внутренняя обработка.
вопрос
- Можно ли определить компоненты React внутри компонентов React?
- Можно ли определить компоненты React внутри функции render()?
Ответ да, и нет. Пример React метода можно использовать как компонент другого компонента. Чувство — это функция, определяющая функции, без проблем.
Но определение компонентов React в render() сделает что-то не так. Это включает в себя первое предположение алгоритма diff.Если компоненты двух рендеров различаются, React уничтожит исходный элемент, а затем повторно отрендерит новый элемент. Это не просто производительность, состояние всех компонентов и их подкомпонентов разрушено. Так почему же определение компонента в render() заставляет рендер думать, что компонент отличается? Поскольку компонент представляет собой класс или функцию, сравнение двух классов или функций в js основано на ссылке на них, поэтому они не должны быть равными.
const a = class {}
const b = class {}
a === b // false
Обычно никто не определяет компоненты в компонентах (это нормально), не говоря уже о функции render(). Но я сталкивался с такой ситуацией, например, с использованием HOC в render().
В последнее время я был занят их написанием.
Напоследок рекомендую статью, которая открыла мне глаза с утра:Разработка приложений с помощью веб-флоу.
Я всегда думал, что такие инструменты, как webflow, предназначены для дизайнеров, которые не знают css для написания веб-страниц. Но компания, использующая фреймворк React + GraphQL, также решила использовать webflow, и он прекрасно интегрируется. Возможно, такие инструменты, как webflow, станут будущим фронтенд-разработки.
Список других столбцов, которые я написалпортал.