Hello guys. Iām quite new to Portal so sorry for a dumb question.
Is it ok to leave tap> calls in the production code? Or this is something that I should add only in dev time and then wipe out before commiting?
Iām not going to use Portal in production, only in dev. But adding taps and removing them seems a little bit odd
Definitely better than leaving prints š
They are basically noops (and the runtime might optimize them away, but I've never tried to confirm that) if there are no tap listeners, so it is okay to leave them in your production code. That also gives you the advantage of being able to attach them at runtime if you have an issue with your system. However, some people don't like them to remain in production code; if you're working in a team you might need to account for that.
I was thinking about what if some dependencies or libraries will define tap listeners then my taps might affect performance in some way
maybe Iām overthinking ))
Libraries shouldn't be defining listeners. They could, but it would be really unhygienic (and I can't think of any example). They can include taps, but listeners should be added by users/client code, not libraries. I wouldn't worry about that.
Thank you š
We have tap> in production code. As long as you don't call add-tap, it's a no-op -- and even if you do call add-tap, as long as you remember to call remove-tap when you're done debugging production remotely, it's fine.
We run both a Portal server and an nREPL server in one of our production processes, so we can connect remotely to it, start Portal (into VS Code locally), and debug production issues -- run queries, run some "readonly" code inside that production app etc.