search

miragejs / discuss

Ask questions, get help, and share what you've built with Mirage
MIT License
2 stars 0 forks source link

Local persistence #4

Open samselikoff opened 4 years ago

samselikoff commented 4 years ago

There was some previous design work done on this feature idea: https://github.com/miragejs/ember-cli-mirage/pull/1028

boshmaf commented 4 years ago

This will be useful if the app checks for a valid auth token in local storage and makes subsequent API calls using the token. Currently, there is no easy way to test this flow, especially if the token encodes some information that needs to be verified against (previously available) records (e.g., check a userId), which I assume is common in many apps today.

I can give this a try, if you think it's worth it. I noticed that there were a lot of code changes in the referenced PR that made it harder for you to move it forward. Any suggestions to avoid this scenario are much appreciated.

samselikoff commented 4 years ago

Ya - thanks for offering to help 👍

The only thing about adding a feature like this to core is it further ties us to the browser and we have some plans to make Mirage work in node + further decouple portions of it from browser APIs. (That being said, today it is coupled to the browser so maybe that's not an issue.)

I would love to understand your use case today. I think with db.loadData() and db.dump() you should be able to test your flow in userland, without any new Mirage APIs. Then we can look at it and see if anything makes sense to extract back into Mirage.

Have you tried writing these tests yet? If not I'd be happy to offer some help!

boshmaf commented 4 years ago

Yeah, db.loadData() and db.dump() should do it. Thanks for the pointer 👍

I don't have the tests yet, but I'll work on them now. Given the direction of the project, I think it's better to avoid introducing more browser APIs, as you mentioned.