What structure should be used to generate a route that accepts a param(s).
Eg.
i have pages/verify.vue which produces a verify route.
However when i use
router.push({ name: 'verify', params: { phone: '+18383' } })
the route is changed to the verify page but the params are discarded because they were not preset on the route.The warning below is thrown:
[Vue Router warn]: Discarded invalid param(s) "phone" when navigating.
What to do to solve this issue without without switching to manual route definitions?
NOTE: I prefer not to have the param values in the url!
Way forward:
It seems file system routes have no way of allowing props through except through the URL. I will be moving on with Pinia (State Management) as a workaround for this task.
OP will be using Pinia for the given use case, as a workaround.
More alternatives are available here: vite-plugin-pages - Route with params/props (Not in URL)
Related
Here is my question about using Svelte/Sapper
I have a file in /src/routes/login.js
According to Sapper doc, it will create an API endpoint in http://<my_domain>/login, which it does
Now in login.js, I would like to call another API server, assume that it is http://another_server/auth
No matter how I use the fetch function: fetch("http://another_server/auth"), this.fetch("http://another_server/auth"), Svelte responses: (this.)fetch is not defined.
The documentation said that it should be run within preload(), so I wrap the fetch under export async function preload(){}, it did not work
So my question is: other than using axios, can I keep on using fetch in server side API request?
Just tested in the template [slug].json.js file, when I add the (this.)fetch function, it did not compile, same error: (this.)fetch is not defined
Thank you very much.
Install the node-fetch npm package and use that in your server routes instead of the default fetch.
(in /src/routes/login.js):
import fetch from 'node-fetch'
...
// inside your route handler
const response = await fetch('http://another_server/auth') // no error
If you are unsure if the code will be executed on the client-side or the server-side (i.e. you're looking for a universal/isomorphic approach) you can use a conditional require:
// inside your route handler
const fetch = process.browser ? window.fetch : require('node-fetch').default
const response = await fetch('http://another_server/auth') // no error
But this is probably overkill in your use case since server routes are by definition executed on the server side.
Suppose I module export "/route1" in route1.js, how would I pass parameters into this route from "/route2" defined in route2.js?
route1.js
module.exports = (app) => {
app.post('/route1', (req,res)=>{
console.log(req.body);
});
}
route2.js
const express = require('express');
const app = express();
//import route1 from route1.js
const r1 = require('./route1')(app);
app.post('/route2', (req, res) => {
//how to pass parameters?
app.use(???, r1) ?
})
In short, route 1 output depends on the input from route 2.
You don't pass parameters from one route to another. Each route is a separate client request. http, by itself, is stateless where each request stands on its own.
If you describe what the actual real-world problem you're trying to solve is, we can help you with some of the various tools there are to use for managing state from one request to the next in http servers. But, we really need to know what the REAL world problem is to know what best to suggest.
The general tools available are:
Set a cookie as part the first response with some data in the cookie. On the next request sent from that client, the prior cookie will be sent with it so the server can see what that data is.
Create a server-side session object (using express-session, probably) and set some data in the session object. In the 2nd request, you can then access the session object to get that previously set data.
Return the data to the client in the first request and have the client send that data back in the 2nd request either in query string or form fields or custom headers. This would be the truly stateless way of doing things on the server. Any required state is kept in the client.
Which option results in the best design depends entirely upon what problem you're actually trying to solve.
FYI, you NEVER embed one route in another like you showed in your question:
app.post('/route2', (req, res) => {
//how to pass parameters?
app.use(???, r1) ?
})
What that would do is to install a new permanent copy of app.use() that's in force for all incoming requests every time your app.post() route was hit. They would accumlate forever.
I'm attempting an implementation of aurelia-authentication with an OIDC provider (IdentityServer4) and seem to be running into an issue with logging a user out.
The short of it is I'm not able to logout users successfully using the authService.logout function mentioned in the OIDC configuration section (https://aurelia-authentication.spoonx.org/oidc.html).
In looking into it a bit further I've tracked it down to a promise rejection in the logout function which provides the message: "OAuth2 response state value differs"
if (logoutResponse.state !== stateValue) {
return Promise.reject('OAuth2 response state value differs');
}
logoutReponse seems to be the culprit as it's coming through as an object with the state property named incorrectly {/login?state: "qAIxYwKqLHYJtyar2PfdvaROWT1O56P7"}.
I can actually change the if statement to:
if (logoutResponse['/login?state'] !== stateValue) {
return Promise.reject('OAuth2 response state value differs');
}
which seems to be working fine, but requires us to modify the aurelia-authentication source directly.
Any thoughts from anyone as to why the "state" property is coming through as a relative path instead of just "state"?
So after spending more time on this I was able to track the issue down and find a solution.
The solution was to change the aurelia-authentication authConfig postLogoutRedirectUri value to just the root page (http://localhost:8080). Additionally, I needed to define that URI under the PostLogoutRedirectUris within my IdentityServer4 Client definition.
logoutResponse was then coming through correctly with a property named state property that holds the correct value and permits the redirect successfully.
I've the following routes defined, I don't understand why express is trying to use the first route and throwing cast error when I call the second route. sub is not a route param, but still it is consider so.
app.get('/api/main/:id', requestId, abcController.findOne);
app.get('/api/main/sub', requestId, abcController.findAll);
I added a route in my docpad.coffee file to handle form submissions, that I validate using the express-validator middleware. Now depending on the validation, I want to redirect the users to the same contact page but displaying either a success message when validation is successful (here I'll send an email), or display the error messages.
I didn't manage to pass the validation message to the template to display it. I tried almost all combinations of dynamic: true/false, res.locals = validationMessages, res.sessions = validationMessages, res.templateData = validationMessages with no success.
Furthermore, adding dynamic: true made the changes to the content not appear at all, whatever refresh strategy I use (private mode, cleaning cache, relaunching Docpad, refreshing without cache, etc.). I should probable file a bug about it.
How to ?
I'm using Docpad 6.53.0 (latest to date), node 0.10.15, on OS X 10.8.4
I cheated on this one a bit by appending a hash to the redirect url (eg: "www.mywebsite.com/#messagesent"). I then use client side javascript to read the hash and then show the appropriate message. Something like this:
if (location.hash == "#messagesent") {
$('#message-sent').show();
setTimeout(function () {
$('#message-sent').fadeOut(1000);
}, 1000);
}
Not quite what you were asking though :)