Alexey Taktarov comments

Results 49 comments of


Alexey Taktarov

Redirect not triggering re-render when used with useHashLocation hook

Hey @sirianni, thanks for pointing out to this issue. You can fix that by either implementing a similar check `checkForUpdates()` or using `useSyncExternalStore` hook (available in React 18, also has...

Expose navigate, not requiring to subscribe to location state

I see that you already made a PR, while I was considering the ideas! There are things I'm absolutely up to like that there is no need to subscribe to...

Expose a `subscribe` function suitable for React's `useSyncExternalStore`

Nice! I think we could switch to `useSyncExternalStore` entirely in the next major release. I guess we can support React 18 as a default target, all previous versions can use...

Expose a `subscribe` function suitable for React's `useSyncExternalStore`

FYI: I've updated our example from the docs with hash-based location to use `useSyncExternalStore` https://github.com/molefrog/wouter#customizing-the-location-hook

Expose a `subscribe` function suitable for React's `useSyncExternalStore`

Thanks, updated the example.

Make a more robust nested routing structure possible

Hey @HansBrende. It took me a while to wrap my head around your solution, it was really smart and nice approach, however there was something in the API design that...

Make a more robust nested routing structure possible

Closing in favour of #265

Discussion: leaky implementation for pushState/replaceState events

Hi @jvdsande ! I anticipated this 😄 I currently lean towards flagging, as it seems like the most user-friendly method, although not the purest one (modifying the environment is always...

Discussion: leaky implementation for pushState/replaceState events

Perhaps, we could use something like: ```js Object.defineProperty(history, Symbol.for('wouter'), { value: 1 }) ``` (might need to test that under different conditions, not sure that history is mutable everywhere)

Discussion: leaky implementation for pushState/replaceState events

> Thinking about @molefrog's comment on window.history mutability, I guess the simplest workaround would be to store the "symboled" entry... On `window` itself. At least we're sure it's mutable everywhere...