Search
Write a publication
Pull to refresh
2
0.1
Send message

Понравилось, спасибо

В конце вы описали кодом крутые примеры, но хотелось бы ссылки на песочницу или гифки. Я ленивый, простите )

давайте там где :has вместо +, если вы не против?

Мне для самообразования. Вот вы указали, что централизованный кеш не подошел из-за того, что это сетевой запрос.

Но в тоже время вы заюзали "централизованную" кафку. Разве общение с ней, не есть сетевые запросы или ... ?

Если вы ждёте от сообщества помощи, то выбрали неправильную стратегию общения с ним.

Иронично

не, это скорее типа парирование. Вы выдвигаете это как минус, я просто говорю, что это можно починить.

А удобство - дело вкуса. Мне, как фронтендеру - да, более чем. Бэк сторону не знаю, поэтому и не сужу

GET /v1/users/:id - это плохо! в списке запросов инструментов браузера в строке будет показан одинокий нечитабельный айдишник, а полный путь с методом отображается только по дополнительному клику в отдельной вкладке .

так это ж настраивается

Я кажется понял вас.

Нет, я не хочу изменяя ref.current заставлять компоненту ререндерится.

Мне не нравится решение проблемы, которое предложил автор. Хук переписан так, что с наскоку непонятно, что в нем происходит, приходится вчитываться, а я это не люблю.

Я бы предложил решать проблему все таки через ссылку и первую реализацию(якобы косячную), потому что она приятно и легко воспринимается.

Всего лишь вместо

const elemRef = useRef();

useResizeObserver({ elemRef, onResize: handleResize })

<div ref={ref}/>

Сделать

const [elemRef, setRef] = useState();

useResizeObserver({ elemRef, onResize: handleResize })

<div ref={setRef}/>

Тут "движок" реакта разберется когда сетнуть новую ссылку на элемент, а когда она осталась неизменной. Но все таки есть конечно слабые места, но пока до них не дошли, мне кажется, что первая "косячная" реализация хука более приятная, очевидная и менее запутанная

ааа, вы про это.

конечно изменение рефа ничего не триггерит

Я лютый приверженец MobX, но справедливости ради стоит отметить, что в нем тоже все , что читает observable поля должно быть завернуто в observer, у которого под капотом React.memo

Что будет с useHover, если элемент который к нему подключен рендерится по условию и вдруг исчез, а потом появился?

В 4 хуке вы упомянули про производительность, но в хук воткнули useLayoutEffect. Зачем он там? То же самое и в 5

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  reset: () => set({ count: 0 }),
}));

Ну как это нет бойлерплейта, чтобы его не было, должно было бы выглядеть так:

const store = create({
  count: 0,
  increment() {this.count += 1},
  reset() {this.count = 0},
});

Это вопрос не вам, а к примеру кода от markelov69

Почему вам нравится
new A().effect1().effect2().......effectN()
но не нравится
new A(A.effect1(), A.effect2(), ..... A.effectN())

Мне со стороны кажется, что только в этом разница, нет?

Ну как же. В самом описании хука useEffect написано, что если значение в массиве зависимостей отлично от предыдущего рендера, то реакт дернет useEffect

Не будем тратить время на детальное объяснение того, что происходит в коде выше

Давайте все таки разберемся. Вы используете хук useRef, который создает объект с полем current на все время жизни компонента. И ссылка на объект останется неизменной. Это важно.

Далее в этот объект вы в зависимости от условия кидаете новые ссылки на DOM элементы.

Но в хук useResizeObserver вы все также передаете ту статичную ссылку на объект рефа. Это первый звоночек, который я заметил. И далее в хуке заметил, что useEffect тоже подписан на ту самую ссылку, которая статична.

Попробуйте не переписывая ничего заменить:
useResizeObserver({ elemRef, onResize: handleResize });
на
useResizeObserver({ elemRef: elemRef.current, onResize: handleResize });

Т.е. я (хоть уже и не молодой) достаточно часто могу переиграть кошку в игре "кто кого цапнет на скорость".

мне кажется тут надо внести детали. Когда вы играете в эту игру, вы пользуетесь вашими знаниями о поведении кошки и некой стратегией. То есть вы планируете рассчитываете ее действия и с высокой точностью предугадываете его. На что уже достаточно легко среагировать. Кошка же наверное каждый матч ведет без какой либо тактики и уж тем более стратегии(максимум тихо подкрасться), а чисто интуитивно атакует/защищается.

Думаю если кошке накинуть навыков стратегии и интеллекта, то наверное это для вас будет как бой с профессиональным боксером или вроде того. И там ваш процент выигрыша будет не такой уж и большой.

П.С. У меня есть кошка и когда я с ней намеренно воюю, то я выигрываю. Но от внезапного "кусь" увернуться мне очень редко удается, а удается только тогда, когда я вижу, что "что не то, ща чет будет".

Видел проекты на 30+ мб рукописного реактовского кода, где обернуто абсолютно все и видел такие же проекты, где ничего не обернуто. Это все конечно ЦРМки были, но все же разницы не чувствуется

brotli же уже, какой gzip

Information

Rating
7,204-th
Registered
Activity

Specialization

Frontend Developer
Senior
JavaScript
TypeScript
CSS
React
MobX
CSS-IN-JS
Webpack