If the functionality you need from the library works, it'll continue to work just fine. With that being said, a lot from that library is either not needed with modern browsers or a bit questionable (like the UI stuff).

Thanks! I'm interested in goog.net.Cookies in particular, after seeing its use in https://github.com/reagent-project/reagent-utils/blob/master/src/reagent/cookies.cljs as part of https://github.com/reagent-project/reagent-utils. Do you consider goog.net.Cookies unnecessary or questionable in the context of modern browsers?

It's alright. Not necessary but convenient and not questionable.

This one from npm will probably do the job: https://www.npmjs.com/package/js-cookie

i found some of the most particularly useful goog.* to be around the stateful session-related stuff in the browser. they have really good activity tracking [of course they do, it's google] and expose very reliable interfaces for things like: "if the user hasnt been active in 5m, do a thing". because browsers bend over backwards to maintain existing compatibility, i think you'll be fine using it for a long while.

GCL is relatively stable, and most of its usage in your code is likely from third party CLJS libraries wrapping around it. If you fear the library having unfixed bugs or security bugs, then I recommend ditching those wrapper libraries and using the JS standard library, which likely has what you want. e.g. goog.crypt.base64 is unnecessary nowadays and likely slower than simply using btoa and atob similarly, goog.crypt.stringToByteArray and related functions can be replaced with TextEncoder and TextDecoder from the JS standard library goog.net.XhrIo isnt really needed unless you have a hard requirement of supporting XHR quirks in ancient browsers like Internet Explorer 8. so on, so forth

JS is non-blocking, so <!! cannot be implemented there. Also, unless you really need to manage communicating processes, there's little reason to use core.async with CLJS. There are more downsides than upsides.

Thanks a lot for your answer. I'm currently studying an example app which uses core.async. But then, how is one supposed to read a channel outside a go block? Can it be done?

No.

Or rather, it can be, but you have to pass a callback.

So you can't use in a way that would make it seem as if it were a return value.

Ok, I'll try that. Again, thanks.

I explored this a few years ago and at least back then json-schema + ajv was the closest.

I guess the trend is to lean on Typescript typings in js-land and there’s not that much push for data driven schemas

there seems to be a whole lot of options, but ajv is the only thing i've found that uses data literals for some reason. every other tool is really invested in().the().builder().pattern() which seems really hard to compose and build other tooling around

ah, yes. typescript might be the reason behind that ...

Some convincing might be needed to make others write schemas instead of TS types. 🙂 You can generate TS type declarations from json-schema though

One point for data driven schemas is that if you have a highly dynamic system and it would be good to be able to construct or modify schemas dynamically. With types you end up with a generics-nightmare if you try to achieve that.

Schemas can be transported over the wire, stored into a db etc..

i agree. we're in the fortunate(?) position of not relying on TS right now. i'm trying to slowly introduce the team to some opt-in data-driven specifications. from the little bit of exploration i've done, i think i might be forced to use ajv just to maintain the data-first properties we're talking about

Ajv is not that bad IME 🙂

Of course the dev-experience is subpar to what you’re used to with schema/malli + the REPL

it's so strange how seemingly noone else thought a data literal based spec tool was worth it. they jumped right into stateful javascript functions/prototype/class constructs. and yea, i'm already feeling the pain of no more repl. it's kind of like one hand tied behind my back 😕

i kind of wonder if protobufs might get me there ... at least it's data oriented.

I tried mimicking repl-driven development with node-js repl but it was not great. Fine for small experiments though… as long as you remember to erase all const definitions before sending to repl 😄

Depends what you’re building but if it’s anything “high-level” I recommend json-schema over protobuf

thanks for the consultation session, i appreciate your time

No problem, I’m happy if this was helpful. Good luck! 🙂

browsers restrict direct file access for security reasons, so no it requires http for good reasons

Sure. But is there some way to make the url/icon config available in some other way? Include a link the the HTML?

I don't know what you mean by "url/icon config"

It's a list of URLs and icons to show in the page for quick links. Right now it's an edn file. I left it in a separate file so it would be easy to update the list as needed.

If I put them in the cljs source, that works, but means rebuilding and deploying if the list changes.

well you could make it a JS file I guess

accessing random files is not possible via JS, at least as far as I know

hmmm include it as JS and then reference the object it creates

I'll play with that

Thanks a bundle. That worked great, and it wasn't obvious to me.