Best alternative: cancel/preventDefault() the spfclick event and call spf.navigate() myself. Then I can easily specify spf.RequestOptions. Unfortunately, canceling that event causes the entire page to be reloaded. So, that also doesn't work.
Therefore the only way for me to call spf.navigate() with my desired spf.RequestOptions, is to add my own click handler, but that requires reimplementing all of the logic necessary for determining which clicks to actually handle: spf.nav.handleClick_() and every function that that calls. (I couldn't reuse that function nor any of the functions it calls, because they're marked @private, and the compiled/minified/built/production build of spf.js thus makes them inaccessible.
So:
Did I do something wrong? Happy to hear so!
If I did not do anything wrong: how do you propose I solve this? Would supporting use cases 1 or 2 make sense?
https://github.com/nicksay/spfjs/commit/acf8727eadf6359548ac967b28c6750b9f1cc8e9 (part of #390) introduced a way for custom request headers to be sent along with a particular request.
Unfortunately, it's not at all trivial to call
spf.navigate():spfrequestevent and specify request headers there. But the event doesn't allow me to specifyspf.RequestOptions.preventDefault()thespfclickevent and callspf.navigate()myself. Then I can easily specifyspf.RequestOptions. Unfortunately, canceling that event causes the entire page to be reloaded. So, that also doesn't work.spf.navigate()with my desiredspf.RequestOptions, is to add my ownclickhandler, but that requires reimplementing all of the logic necessary for determining which clicks to actually handle:spf.nav.handleClick_()and every function that that calls. (I couldn't reuse that function nor any of the functions it calls, because they're marked@private, and the compiled/minified/built/production build ofspf.jsthus makes them inaccessible.So: