Clojurians Log v2

Besides great SPA capabilities. Is there something similar to what NextJS does in the Clojure(script) world?

What capabilities are you looking for?

Why ^js in (fn [^js this] might me needed? Is it some optimization I guess?

yes. see https://clojurescript.org/guides/externs

how do I resolve such a warning? Probably a type hint somewhere...

Cannot infer target type in expression (. el getScreenCTM)

Having for example static pages, dynamic pages with link preview. I guess what I am looking for is SEO friendly capabilities

el in this statement cannot be inferred by the compiler, putting getScreen in danger of being renamed during advanced compilation. The simplest solution is to put a ^js type hint where el is declared.

Thanks! Seems kind of... obvious that the result of a js method on a js object is a js object but ok

More specifically, say I have a dynamic part of the application which can be an SPA, but also have a blog part with the blogposts written in Markdown but compiled to html pages at build time

How would you go about doing that, currently I am looking at the luminous framework but seems that all pages are built at request time

This one was just poste above this question, probably informative https://clojurescript.org/guides/externs

yea I saw it hmmm

@pepijndevos but how did you get el ? generally it's not possible to know what it is

there's plenty of inference in ClojureScript but still typical cases that cannot be known in a dynamic language (fn params etc)

yea in a statically typed language (.-currentTarget aMouseEvent) would have a pretty well defined type... not so in dynamic land

even that is not completely true

once the type is known inference can flow

if the type is standard DOM, types are collected from Closure

the problem is not inference - the problem is what is the initial type

even in most statically typed languages you need this critical bit of info

and you are forced to declare

the moment you type el than all types will flow correct in the local context and ClojureScript even infers return types

not for type checking of course (except a little for numerics) - mostly for extern generation (and elimination of externs already declared)

we even check usage - if you use the right type but then call the wrong method - you will get a warning about the method be unresolveable

I would say this has probably not much to do with dynamic vs. static, since you have all kinds of different issues around the same interface and same problems with static languages as well. In fact, with static you have worse issues, e.g. like this https://github.com/microsoft/TypeScript/issues/299 I personally been bitten by this, never could properly write type signatures for DOM methods. If you don't avoid the whole problem completely, e.g. like how elm-lang does it https://guide.elm-lang.org/effects/ then I guess it's possible, but even they had to iterate on this concept several times, and I am not sure this will be final (looks so, so far).

https://clojurescript.org/news/2021-05-24-release

This (from the release notes ^) is really cool:

(ns foo.bar
  (:require-macros [foo.baz :refer [macro-that-expands-to-require]]))
(macro-that-expands-to-require)

Still looking for an answer to this 😁

@ovidiu.stoica1094 just use NextJS w/ ClojureScript?

I am not really keen on that sollution as I want to port my existing Next Js implementation to full Clojure & ClojureScript as my backend is already in Clojure w ring & reitit and I would love to get some static pages like for a blog (SEO) and dynamic pages like domain/vote/:dynamic-id for which I just want to generate a preview link for social channels.

I don't know if there is a complete solution like NextJS - if I had a good excuse I would do a project with Datomic Cloud Ions

Datomic Cloud Ions… I am not familiar and I haven’t used datomic yet but will look into it

Hello, How do I make that time will be displayed on users browser locale and with their local timezone displayed as well?

Use a library, for example https://github.com/juxt/tick

If one wanted to make a CLJS plugin system with one base module and other optional modules, with advanced compilation, the :modules system could work. It does work in fact, if you compile all modules from one and the same repo and commit. BUT: what if other parties also wanted to make modules? The advanced compilation naming scheme isn't deterministic/stable enough in this situation. What to do? Revert to simple? Is there a better option? How do other JS libraries tackle this problem? I guess in pure JS there are less problems because you don't have to depend on the same cljs build Perhaps :pseudo-names could work, although the docs suggest this is for debugging and maybe not a good idea?

not possible with advanced since that is a whole program optimizer. well you can create an "interface" that other modules implement but as soon as you want to use CLJS datastructures you'll run into trouble. JS libs don't generally have this issue this they mostly build on JS objects/arrays

:pseudo-names is for debugging only

yeah, that's what I thought. the interface idea might work too but then each module would have to bring their own mangled versions of the entire cljs lib :)

exactly

I think in theory it would be possible to compile the base module with advanced and then inform the advanced compilation of the other modules about the naming scheme used, to take those into account

but Closure would have to support that

no that is not possible. :advanced will remove everything that isn't used, so how is it supposed to know what modules will use in the code it can't "see"?

if you disabled that you end up with :simple again

the optional module would be compiled with, let's say, a map of raw names -> mangled names, so everything the optional module would use in common with the base module, would get the same mangled name. If code is cut out from the base module, but is used in the optional module, the name doesn't matter, since the only assumption is that the names of the base module are mangled consistently.

it isn't just about names. things will get inlined, moved around, deleted.

yeah good point, then it doesn't work out

you can simply turn off the renaming of properties but that won't really safe you.

ok, so the plugin system would be a closed system, unfortunately

yeah sort of the same deal as graalvm native-image

open for contribution of course, but not something that can be developed independently

yep

another question, different topic. how common is this-as in normal every day code?

for some interop code it can be common. otherwise very uncommon.

At that stage wouldn't it make more sense to make your primary system a library and deployments just depend on the library and a fixed set of plugins, and then advanced compilation only takes place with all the code already in your system?

@suskeyhose normally yes. The use case for the plugin system would be for this: https://borkdude.github.io/sci-script-tag/ so you can make an optional reagent plugin: https://borkdude.github.io/sci-script-tag/tictactoe.html and that works well, as long as you compile from the exact same code base.

aaaah, I see

"not possible with advanced since that is a whole program optimizer" Aha! That explains the two days I spent trying to sell multiple repos to advanced! sigh