Fork me on GitHub

I think I've caught a bug, when calling load from :started-callback if you have a not so great connection, then the loads will be sent before the websockets connection is established. I was assuming it was my hot reload logic getting in the way because it was kinda shakey so I started using setTimeout. Sometimes the sente error Chsk send against closed chsk. would appear. After deploying my app on a server a continent away it would never work for me, but would work for people in that area and the error would appear even though I didn't have my hotload logic. It seems the sente author suggests not sending anything before the :first-open event:


Maybe this is not a bug and you're just not supposed to send from :started-callback. But thought I'd mention it.

đź‘Ť 8

I’d consider that a bug, I think. Sounds like the networking logic in the websockets implementation needs to queue up requests until the first open event…and I don’t think it currently does that.


Version 2.5.5 Released. Includes a few bug fixes and support for React 16's error boundary lifecycle method.

🎉 28

The other new lifecycle methods require some careful consideration on our components, since we hack into the lifecycle to provide UI refresh optimizations. For the moment all of this is compatible, but in React 17 we’ll have to definitely move away from some of the old lifecycle methods.


Today we were discussing at work on how to translate something that contains a link. Such as Open the docs by clicking here and here being a link to some page. I was wondering how you folks solved this case.


@fatihict couple of ways to approach that kind of thing: 1. re-word your link so the entire message can be the link: (dom/a {...} (tr "Open the docs")) 2. Use your own invented marker for markup, and post-parse the translation: (let [xlation (tr "Open the docs by clicking {{here}}") ...). I.e. then look for the {{…}} segment and translate the thing to your DOM…painful, but you could write a general function to do that if it comes up a lot.


I personally prefer (1).


esp. since making “here” a link is kind of an HTML anti-pattern.


But the problem does come up that formatting might need a DOM translation. I consider that a problem outside of the built-in i18n support. You could, for example, support a subset of markdown, and use a react markdown translation…then you’d could do things like:

(md/markdown->react (trf "You **really** delete {filename}." {:filename f}))


which even has a cljsjs wrapper…and is what devcards uses


Supporting markdown is a cool idea


I also prefer option 1, but that's not always an option.