-
Notifications
You must be signed in to change notification settings - Fork 20
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
CLJS version? #30
Comments
Hello! I can't tell from your description whether you have a use case in mind involving browsers or not. If you're just targeting node, then I'm unopposed, but if there's some way you imagine browsers being involved then it might help to give a detailed example. W.r.t. forking, I imagine a lot of code could be shared between the two via cljc, so keeping them together seems worth it. You'll have to put up with my slow pace for reviewing/responding though, so obviously you could make a temporary fork in the meantime if you'd like. |
Right, I'm talking about both to be honest 😄 I'll try to cut something, but the idea is that most ClojureScript development environments today (Figwheel and Shadow) have a way to start a "backend handler" like Shadow-CLJS' So the idea I had (I still need to check if it'll work) is that if I could, in some way, create a macro that would call this handler to get the cassetes, then pre-define them. This means that, for browser targets, VCR will need to have some way to "refresh" cassetes otherwise deleting them on the filesystem will not work at all (because the value from them will be cached). I'll try to hack something and show you. In Node.JS file, it's indeed easier because we can always use |
Sounds good, I'm looking forward to seeing it. |
Let me say: thanks a lot for this project, it's surely the best "VCR" library that I used in all of my projects!
Now, to the point: I want to port your code to CLJS. I'm thinking about a way to manually inform VCR when cassettes were changed on your local machine, so it can re-cache them again (that's needed because ClojureScript may not have synchronous file reading, for example in the browser, so it'll not be able to "record" calls that are sync).
Probably the API can be a little clumsy to use (because, again, it'll only work seamlessly on Node.JS, not on Browser targets, so a quite hard limitation) but even them, I think it'll be really useful.
Now, the question: do you want me to make this code, and then open a PR for you? Or do you prefer that I keep a fork (let's say,
vcr-cljs
or something) so that the code don't mix? Also, if you have any questions on how I intend to do this API, feel free to ask here.Thanks again for this project!
The text was updated successfully, but these errors were encountered: