Dave Wasmer

@courthead appreciate the tip, didn’t know about `onerror`! The query param solution feels a bit iffy though - potential collisions with in app qp’s for example. FWIW, we ended up...

I realize that in an ideal world, even your dummy app wouldn't have duplicated versions of addons. But unfortunately, sometimes other things take priority, and we simply don't have time...

Apologies for the messy diff - I thought I skipped those hunks when adding, but I guess not. On that thought - @neumino, would you be open to a PR...

My use case is primarily around reflection. I'm trying to serialize a Thinky model into different JSON formats, without hardcoding per-model serializers. So having the ability to export the schema...

I'd suggest that the initializer should also be robust to Stripe.js failing to load. If Stripe's JS CDN goes down for whatever reason, that shouldn't also take my entire app...

Facing a similar issue here. I've created a reproduction repo here: [davewasmer/throwaway-sandbox](https://github.com/davewasmer/throwaway-sandbox). If I create a Vercel app and connect it to this repo using the Git integration, the deploys...

Hmm, interesting. I like the options hash, but this makes me think that maybe actions should be their own class perhaps. You can pass arguments to an action at invocation...

Maybe a middle road approach would work, something like how ember-validations does custom validators. You can define it inline if you want, or as a separate class. I'm not sure...

But that still feels like it's coupling to the adapter too much. What if you have a non-RESTful adapter, or even localStorage adapter, where a `postAction` might not make sense?...

In some sense, that was my goal with having an adapter layer and a model layer definitions for actions. Your adapter action would fire the appropriate ajax request or whatever...