portal

ts1503 2024-10-29T10:58:05.779949Z

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

Mateusz Mazurczak 2024-10-30T20:41:47.366409Z

Definitely better than leaving prints šŸ˜…

R.A. Porter 2024-10-29T11:57:34.172199Z

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.

šŸ‘ 1
ts1503 2024-10-29T12:00:01.785049Z

I was thinking about what if some dependencies or libraries will define tap listeners then my taps might affect performance in some way

ts1503 2024-10-29T12:00:38.268779Z

maybe I’m overthinking ))

R.A. Porter 2024-10-29T12:02:56.649629Z

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.

ts1503 2024-10-29T12:10:15.460739Z

Thank you šŸ‘

seancorfield 2024-10-29T15:54:26.522509Z

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.

šŸ‘ 2