All streams
Search
Write a publication
Pull to refresh
2
0
Send message

именно тот, что выше с функцией - примерно наверное никогда)

Но вот чтобы сделать быстрый доступ по id из мапы - почему нет

const users = [
{
id: '1',
//...rest,
}
]

const usersMap = users.reduce((tempUsersMap, userData) => ({...tempUsersMap, [userData.id]: userData}),{});

const userById = usersMap[users[0].id]

разные - все верно. Сущности разные, тип одинаков. По сущностям - одно из "ordinary" второе из "non ordinary -> exotic"

например если хочешь высчитать ключ динамически

const obj = { [(() => {
//...some logic
return 'new key'
})()] : 'test'}

эмм, да, а где минусы то?

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

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

давайте там где :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

Information

Rating
Does not participate
Registered
Activity

Specialization

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