Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change api to middleware #35

Closed
AndrewBogdanovTSS opened this issue Feb 12, 2018 · 3 comments
Closed

Change api to middleware #35

AndrewBogdanovTSS opened this issue Feb 12, 2018 · 3 comments

Comments

@AndrewBogdanovTSS
Copy link

AndrewBogdanovTSS commented Feb 12, 2018

That's just a suggestion. Since we don't have any example of a middleware inside a template but we use an undocumented api folder which is just a discrepant addition in my opinion. Why not use middleware as Nuxt intended? api/people.ts can be placed in middleware folder and rewritten as such:

export default async function({store, error, redirect}){
    if(process.client) return;
    await store.dispatch('getPeople')
}

and in the store actions:

async getPeople({commit}){
            commit('setPeople', await axios.get('/random-data.json').data.slice(0,3));
    }

and in nuxt.config.js module.exports object

router: {
    middleware: 'people'
  },

this way we can showcase how middleware function can be used in the template that might be beneficial for a lot of users

This question is available on Nuxt.js community (#c30)
@AndrewBogdanovTSS
Copy link
Author

I've created a PR to reflect that change #36

@qm3ster
Copy link
Member

qm3ster commented Feb 12, 2018

Sorry, I reviewed the PR before seeing this.
Like I said, I think this is a poor use of middleware and will confuse people.
Middleware in ts works exactly the same as without, so we don't need to exercise it.
Perhaps if we give typings for the arguments of the middleware function, it will be more useful.

Still, I think we can do much better than the example.

As for the api folder, I thought it was a decent way of abstracting away axios (someone's api might be firebase-client, etc.) and the correct place to typecheck the returned values and handle network errors, returning the store or other caller a parsed data promise.

@AndrewBogdanovTSS
Copy link
Author

I guess this issue can be closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants