Iterator protocol perhaps..?

Hmmm you're probably right.

There are libs that AFAICR approximate that, I think, assuming you mean generally, lazy iterators ( operations like map etc done lazily or aggregated unlike with regular js arrays ). However, I cannot remember 😞 as it's been a while. That being said I am interested in this somewhat, and if you're still looking it might be fun to try to help you find what you're looking for,

Before I even asked here I made my own simple wrapper around an array. It's just a class that takes in an array and does a super naive index increment with a check to wrap back around to zero.

There are some easy improvements over my current version just by using a better base structure like map/set. AFAIK internally js/ts probably just use arrays for the same, may an object as a hash map for quick access. To actually get some niceness in terms of operations and use, doing something based on iterators does seem viable. There's also generator functions, which are pretty under used in the js world but are probably perfect for this sort of thing.

Here's the current version I'm using:

export class Sequence<T> {
    private index = 0;

    // TODO: Consider cloning array for safety
    constructor(public elements: Array<T>) {}

    take(n: Number): Array<T> {
        if (n < 0) return [];

        const nArray = [];

        for (let i = 0; i < n; i++) {
            nArray.push(this.consume());
        }

        return nArray;
    }

    public current(): T {
        return this.elements[this.index];
    }

    public consume(): T {
        const element = this.elements[this.index++];

        // Naieve Cycling
        if (this.index >= this.elements.length) {
            this.index = 0;
        }

        return element;
    }

    // Weirdly defaults to moving to 0 if element not found
    public moveTo(e: T) {
        const index = this.elements.indexOf(e);
        // Ternary to scrub default to 0
        this.index = index === -1 ? 0 : index;
        return this; // Hack for creation
    }

    public moveToIndex(i: number) {
        this.index = i;
        return this; // Hack for creation
    }

    public moveForward(n: number) {
        for (let i = 0; i < n; i++) {
            this.consume();
        }
    }
}

On the server.

If on the server, then why can’t we use macro inside a repl?

No clue about nREPL, but I was able to use a macro just fine with a regular REPL.

And there are no GitHub issues in the nREPL repo about not being able to use macros, so my guess is that there's something wrong in your setup or macro usage.

There is the link here: https://cljs.github.io/api/cljs.core/defmacro#:~:text=A%20side%20effect%20of%20this%20is%20that%20you%20cannot%20use%20defmacro%20from%20a%20REPL.%20Sorry!

Ah, well - initially you wrote about "using a macro", not "using defmacro". Those two are completely different.

Yeah. I am not sure about this part. What’s the difference?

"Using defmacro" is writing code like this: (defmacro my-macro [form] (do-stuff-to form)). "Using a macro" is writing code like this, assuming the above is already written somewhere: (my-macro [1 2 3]).

I'm 70% certain that you can use CLJ REPL to create a macro NS and define a macro there, then start a CLJS REPL from within that CLJ REPL (so it shares the same process) and use that macro in there.

yes, macros are written in CLJ. you cannot write them in a CLJS REPL

a CLJ REPL is fine though

I primarily don’t understand why a cljs repl cannot write defmacro given that the underlying COMPILATION envrionment is on JVM, only the execution of code happens on browser or node.

thats just how it works. macros run in the CLJ runtime so thats where they are defined.

delay might be more suitable.

delay would not be subject to DCE?

DCE is apparently finicky enough, according to a discussion yesterday or the day before, so I can't say. And it probably depends more on what the functions you mentioned do rather than delay itself.

yes, delay is eliminated if never used

if you however put the even underef'd delay into a map or so that might not remove it anymore

(def string-transformer (delay (transformater ...))) will be removed if string-transformer is never referenced anywhere

oh, that’s perfect, didn’t know that and it’s really easy to incorporate. Thank You! 🙇

> It requires that the component be converted to a string What do you mean? QontoStepIcon is never converted to a string, which, I assume, is what you mean by "the component".

Also, the question would probably be better suited for #reagent, assuming that's what you're using.

This is an example from the material-ui 4 docs. I'll clean up the question and move it to #reagent.

And if you just want to be able to supply the StepIconComponent property, you need two things: • Passing "StepIconComponent" instead of :StepIconComponent - assuming that the latter doesn't work (I don't recall) • Wrapping your own version of QontoStepIcon in reagent.core/reactify-component.

In my case I'm just passing a function that defines an svg-icon component. I want to pass that icon to the StepLabel component to replace the default.

Well, my previous message is still applicable.

That worked. Thanks. So what reagent.core/reactify-component does is turn a function/input into a react component.

So could I have done (defn stepper-icon:f []) which would have the same effect?

I have no clue what you mean by that.

I meant (defn stepper-icon:f []).

StepLabel expects a proper React component. Your stepper-icon:f is just a function, nothing more - why do you think it would work?

the :f , doesn't it convert a function into a React component?

First time I hear about it. And Reagent source code doesn't seem to have anything that would work that way. But it does have :f> however. But that's for the reverse - for using functional components in Reagent hiccup vectors.

> Is it possible to hack on clj-lsp or calva or something Probably, but sounds like it would be better asked in #lsp or #calva since what you describe is very tool-specific and not language-specific.

Also, just as an extra bit of info - I doubt there will be significant support for this feature. Interop with JS is somewhat niche, and it's currently non-existing with TS simply because CLJS compiler can't consume TS code at all. And CLJ community itself is also somewhat type-averse, understandably so.

Thanks @U2FRKM4TW for the pointers, will x-post! Was imagining though that #clojurescript members have had more interop exposure than #lsp or #calva. FWIW my post has 2 agendas: 1. To find others who a. agree with my aims suggested above i. and have tips for scratching that itch b. or pointers to existing works that have started to 2. And/Or to pick the brains of people who have: a. both i. written robust projects from scratch ii. and have made large, wide-ranging contributions to very large existing codebases, b. in both i. clojure/script ii. and Typescript 1. (as opposed to Java/C#/really type-intensive langs where type-aversion feels less controversial in comparison) c. So that I can gain perspective, tips, advice, tooling, etc or simply their thoughts in general. Sorry for the verbosity, anyways, thanks for the response!

Maybe look into any projects that take *.d.ts files and convert them to https://clojure.org/guides/spec or https://github.com/metosin/malli definitions. Both have a way to spec functions. If there isn't one, there's an opportunity to contribute. Then existing tools like clojure-lsp could pick up the clojure.spec definitions and provide some of the hints you're looking for.

As for in-project constraint/contract checking, look into using clojure.spec or malli with "instrumentation". This would run the specs in your dev version of the app, admittedly at runtime, but you could write and run a test suite with instrumentation and have a static-like type experience that way.

If you REALLY want to go the typed route, there's https://typedclojure.org/, but I have no idea of the status of the project.

I would encourage you though to investigate why Rich Hickey and the Clojure community have opted for specs over static typing. Check out the videos: https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=2V1FtfBDsLU

That way you have a deeper understanding of the trade-offs Clojurists are thinking about when it comes to choosing Clojure over a statically typed alternative.

My stance, at least currently, is that we can get pretty close to and even farther than a statically typed lang like TS. Consider https://practical.li/clojure/clojure-spec/ and specs including checks beyond just types. Not to mention that we can rarely guarantee that our types are 100% correct 100% of the time for outside data coming into the system, making runtime checks much more valuable.

That of course comes with some perf trade offs in dev and testing. But the beauty of specs are you can pick and choose where to use them. Unfortunately I can't speak to all this in practice in the large scale. So someone else will need to chime in there.

Also, have a look at this link for a static typing like experience https://github.com/jeaye/orchestra

With Clojure-LSP you get some refactorings for free. Rename symbol is one. I bet more can be added. I see your point about wanting to address the larger community - but I still think you should make those who follow #lsp and #calva aware of what you want.