Зачем использовать Context и Provider, учитывая реактивность SolidJS?
У меня есть этот проект SPA, который аутентифицирует и авторизует своих пользователей с помощью токенов доступа (JWT). Эти недолговечные токены доступа также имеют свои токены обновления, поэтому, когда срок их действия истечет, приложение должно обновить токен доступа и воспроизвести неудачный запрос(ы). Для этого я придумал функцию (authAwareFetch), которая переносит глобальную fetch в; 1. добавьте заголовок авторизации, если присутствует токен доступа (т. е. пользователь вошел в систему) и 2. проверьте, не завершился ли запрос ошибкой (из-за просроченного токена), обновите токен доступа и повторите запрос.
Чтобы узнать, присутствует ли токен доступа authAwareFetch, импортируйте хранилище токенов (tokenStore), которое представляет собой простое хранилище SolidJS для хранения токена доступа, его время жизни (действителен до времени EPOCH) и токен обновления, созданный createStore из SolidJS.
Чтобы иметь возможность регистрировать пользователей, у меня есть эта служба аутентификации, которая экспортирует другие функции среди login; refreshAccessToken, logout. Сервисный файл также импортирует tokenStore, а его функции считывают и записывают в хранилище.
Учитывая приведенную выше организацию кода (хранения и службы в своих собственных файлах) и возможность реагировать на изменения (в компоненте и вне его, благодаря SolidJS), мой вопрос заключается в том, каков вариант использования Context и Provider? Если я собираюсь импортировать хук для каждого компонента (например, useAuth), не будет ли одно и то же импортировать магазин (для чтения из него) и сервис (для обновления магазина)? Я что-то пропустил?
Заранее спасибо.
Ответы 1
Контекст позволяет передавать значения вниз по дереву компонентов, минуя родительские дочерние отношения.
Допустим, вы хотите использовать токен доступа в компоненте, расположенном на три уровня глубже внутри иерархии компонентов:
const [authoStore, setAuthStore] = createStore({ /* Contents */ });
<ParentA>
<ParentB>
<Child />
</ParentB>
</ParentA>
Вы можете передать хранилище от ParentA к ParentB к Child:
<ParentA store = {authStore}>
<ParentB store = {authStore}>
<Child store = {authStore} />
</ParentB>
</ParentA>
Или вы можете создать контекст и передать хранилище в качестве его значения, чтобы дочерний компонент мог получить к нему доступ напрямую через Context API.
const AuthContext = createContext(defaultValue);
<AuthContext.Provider value = {authStore}>
<ParentA>
<ParentB>
<Child />
</ParentB>
</ParentA>
</AuthContext>
И внутри дочернего компонента:
const Child = () => {
const authStore = useContext(AuthContext);
// Snipped
}
Теперь, если мы вернемся к исходному вопросу, использование сигнала или хранилища не имеет значения, потому что, пока внутренние компоненты имеют доступ к токену аутентификации, вы можете использовать хранилище, сигнал, локальное хранилище или даже простой объект Javascript. Но Context API предоставляет простой способ обмена значениями между компонентами, независимо от того, насколько глубоко они расположены в иерархии компонентов.
Есть дополнительные преимущества, например, вы можете перезаписать значение на разных уровнях дерева компонентов, указав другое значение.
Здесь ChildA получит значение red, а ChildB получит blue:
<ThemeContext.Provider value='red'>
<ChildA />
<ThemeContext.Provider value='blue'>
<ChildB />
</ThemeContext.Provider>
</ThemeContext.Provider>
Через контекст можно передать любое значение, включая сигналы и хранилища.
Спасибо за подробный ответ с фрагментами кода. Насколько я понимаю; 1) Значения контекста могут быть изменены на более глубоких уровнях, 2) Мне все еще нужно импортировать сам контекст (например, AuthContext) и хук (например, useContext). Значит, в моем случае использование Context API является предпочтительным, а не необходимостью? Я думал, что должен использовать его, но возможность создавать сигнал из контекста компонента упрощает организацию моего кода.
Также solidjs.com/tutorial/stores_nocontext