Fork me on GitHub

Any suggestions on boilerplate for Reframe with html and css i.e website header, footer with good styles ? I want to prototype quickly ?


It would just be a Reagent boilerplate since what you describe doesn't have any behavior in it.


thanks but I may need some state in it


And I don’t want to invest too much time in Html and CSS


What I meant is that you can find any Reagent boilerplate/template and just plug re-frame in there without any hassle. Just add a dependency, that's it, you've got state now.

Wesley Matson15:07:47

As far as quick/low-friction styling, I’ve had lots of good luck with which can be used pretty much regardless of the templating/state-management frameworks at hand. (Bulma is css only and using it on any individual element is opt-in)


@lilactown IMO there isn't a need for a doc - all core fns that mirror Clojure's are intended to be used in the same way


If you can think of other cases where you feel inclined to do this, I would be surprised. Using aget / aset in this semantically poor way is a JavaScript-ism, not a Clojure-ism


I have a custom deftype -- if I eval a form that contains a value of that deftype (not via a def), though, the compiler doesn't like it. Is that something that just isn't supported, or am I likely to be doing something wrong?


I'm trying to write a custom graphical repl that lets me paste an image, and this is effectively me doing something like (def x image-value) (where image-value is an instance of my deftype)


To be clear, this eval is in an embedded cljs repl ...


In case that makes a difference.


If I just def it, before passing it to eval, it works, so the data is valid, and the concept is fine within normal cljs.


It's just a little difficult in this circumstance to figure out what the difference is with the self-hosted version ...


failed compiling constant: [object Object]; foo.image/Image is not a valid ClojureScript constant.


you need to make sure the reader is aware of that - it's a bit too involved to explain and I would say advanced topic


because in regular ClojureScript reading has to be fixed in two places more or less for real consistency


and I don't think we did anything different for bootstrapped - it could probably be made a little simpler there


but zero priority - if you want to look into that and fix it up (if something is missing or could be improved) - go for it.


Sure, I understand that none of this is likely to get changed without my effort - I'm just trying to understand it better and not resort to hacks like creating temporary defs to solve the problem. As far as making the reader aware, I'm just surprised that it can't deal with instances of a deftype it should know about. I'm not 100% where to begin looking - as far as making the reader aware, do you think this is something that I can likely fix by introducing a custom reader tag ? I don't really want any kind of data transformation to occur - the data is correct.


oh actually it maybe that the reader is actually already working ...


almost I mean - the error is saying that compiler doesn't know about that constant type - we have cases for one


I think we don't automatically embed these values - this would be an enhancement to the compiler for bootstrapped


look at the constant cases in compiler.cljc


Yeah, I was reading compiler.cljc to take a look to see if anything jumped out at me.


you need a case for each kind of constant - in generally we don't allow embeddings because it doesn't make sense in normal ClojureScript


but in bootstrapped this is not a problem


anyways - this is advanced territory and I can't walk you through it


you could also examine Clojure to see how it's done there


@dnolen Hopefully having been a clojure programmer since 2008 I will eventually be able to tackle advanced topics. 🙂 Anyway, thanks for the help and insight. I will see what I can do.


@pmooser great! then dig in 🙂


I am optimistic! This doesn't seem insurmountable.


sorry a lot of times we get questions about bootstrapped and people want to do things without realizing there's still work to be done


and it's just not a priority because boostrapped isn't a primary use case and never will be


I understand completely, David. I'm grateful that you guys do all the hard work on this stuff so I can write absolutely crazy stuff and it usually works! I know I'm way off in the weeds, so to speak.


I think you need some kind of default case when you know you have an embeddable value


normally we just throw an exception in ClojureScript because it's game over


but in bootstrapped you could say - this is a runtime type we already know about we can embed it


the embedding bit is kind of a head twister - but probably a fun one to sort out


Yes, I will read a bit more of the compiler and see if I can glean some insight about how that might work - but it's interesting and digging into this kind of code will surely help me down the line, sine it's not like the software I write is going to get any less crazy over time ... 🙂


Thanks again!


I will say it might be slightly trickier than it seems but pretty cool


I think the compiler and analyzer will both need to be changed, we don't normally put runtime values into the AST


so I think that's what would need to be done, storying runtime objects as values directly


again I think seeing how this is already done in Clojure would be better starting point


I'll take a step back and take a gander at how it's done in clojure then!


if you feel like you've made some progress feel free to open an minor enhancement ticket for self-hosted in JIRA

👍 3
Brian Amadio14:07:55

What’s the recommended library for data visualization?

Brian Amadio14:07:39

I looked at metasoarous/oz but could not get it working with shadow-cljs


whats the problem?

Brian Amadio14:07:00

Build failure: The required namespace “oz.core” is not available, it was required by “power_calc/views.cljs”. “oz/core.clj” was found on the classpath. Maybe this library only supports CLJ?

Brian Amadio14:07:25

Reverting the version to 1.5.6 in my project.clj makes this error go away but causes other issues

Brian Amadio14:07:38

The above error occurs with 1.6.0-alpha11

Brian Amadio14:07:55

I’ve checked that the version is available in my ~/.m2/repository

Brian Amadio14:07:56

With 1.5.6 it builds successfully but I get a bunch of warnings about deprecated reagent functions, and my cider REPL is not responsive


from the looks of it the 1.6.0-alpha11 is bundled badly and does not contain oz/core.cljs


don't know how far you have to go back to fix it alpha8 also seems bad

Brian Amadio15:07:01

ok guess I’ll add to the pile on

Brian Amadio15:07:15

thanks for the help!


@dnolen So ... the most straightforward route I managed to find is to mimick what is done for emitting fn references (`emit-fn`) - and it works. I'll have to think a little bit about what a general mechanism like this would be - for my test, it relies upon a defmethod for my custom deftype. But I thought you might find it interesting!


just a sanity check... I can use spec to test frontend, right? works in the browser and there is tooling to run it? Because I am unsure how much of the clojure guides and tutorials actually translate to cljs.

Alex Miller (Clojure team)19:07:28

the spec guide should work as is in either clj or cljs

thanks2 6

@pmooser ah interesting was needed for testing specs in self-host, @mfikes worked on that bit I think


@pmooser @dnolen The origin of emit-fn is described a bit here (it is indeed related to self-hosted)


like I said above, I think if we could embed arbitrary values in the AST we could handle this in a more general way and avoid the case by case stuff


but emit-fn is a good jumping off point for thinking about the more general problem


Yup ... thanks for the additional info, I will reflect on it a bit more!