Daniel from WorksHub here. First, let me express our gratitude for pushy – it powers navigation in our app and is an excellent little piece of software. Many thanks!
We found ourselves needing to determine in our dispatch-fn whether the request comes from a user's on-page action (clicking a link handled by pushy), or from a browser history action (e.g., clicking Back). Turns out that it's hidden in the isNavigation property of the Closure Library's NAVIGATE event. This PR passes the value of that property as a second argument to dispatch-fn.
Technically, it's an API breaking change (since dispatch-fn is now expected to take two arguments, rather than one), but I don't have a good idea of how to make it more kosher. I'd be happy to discuss this further.
Hi,
Daniel from WorksHub here. First, let me express our gratitude for pushy – it powers navigation in our app and is an excellent little piece of software. Many thanks!
We found ourselves needing to determine in our dispatch-fn whether the request comes from a user's on-page action (clicking a link handled by pushy), or from a browser history action (e.g., clicking Back). Turns out that it's hidden in the
isNavigationproperty of the Closure Library'sNAVIGATEevent. This PR passes the value of that property as a second argument to dispatch-fn.Technically, it's an API breaking change (since dispatch-fn is now expected to take two arguments, rather than one), but I don't have a good idea of how to make it more kosher. I'd be happy to discuss this further.