Depends on what you want to accomplish. You can make a custom reader type #float that captures the float as a string, while read from a clj-side macro. Then have the float read into a type that calls .parseFloat when printed.

Won't work in self hosted cljs though

However, if you happen to know that the thing was a float type from the beginning, if the number gets coerced to an int, you can just add .0 to it when you print it.

I'm looking to parse <input> values E.g. transform strings into floats, that's all. ended up with my own fn but I'm pretty surprised clojurescript is not providing sane wrapper on top of the well-known js mess

I think cljs would have to permanently box floats and any numbers they interact with, to prevent js from coercing things, which would be a pretty heavy weight solution, iiuc

What are you doing with the data after parsing it? Doing math on it in js?

Or spitting it out somewhere else?

Personally I would use reagent, exactly re-frame 🙂

I know you wrote you don’t use it. But I would start to use it 🙂

Is there a way to use re-frame without lots of boilerplate code?

What boilerplate code do you mean?

I don’t have such feeling about re-frame

well, I am a begginer in clojurescript,

so I figured I will do some server side rendering with hiccup and ring.

And then add some jquery based stuff in the client.

I had a look at several demos of re-frame,

and they seemed all quite complex.

Well the newest solution is https://github.com/bhauman/figwheel-main-template clj -A:new figwheel-main hello-world.app --reagent . But it is the newest solution, so there is not a lot of tutorials how to use cli. clj -A:new figwheel-main hello-world.app --reagent

You can try it, but I warn you it will be hard on the beginning

Not sure what experience you have, decide yourself 🙂

There you have code ready to go

but it this hard is not about re-frame, but about tooling around

this is why I thought that I go with jquery solution first.

as this is way easier.

If you want to start from something simple and easy, start with lein and re-frame template. This boilerplate code is not about re-frame exactly. It can be a few lines to run it. It is more about architecture of app.

But this hard things to learn are not about re-frame. It is more about tooling around clojurescript.

Personally I wouldn’t use jquery with clojurescript

why not?

because we have great tools like re-frame or fulcro

which are newer and better

can I use react components in re-frame ?

I mean out of the box.

there are tons of really good react libraries,

that would be a motivation to use re-frame.

yeah now we are talking about tooling around, because using npm dependencies in cljs is not easy, but it is what you can do.

Choose one topic, figure out it and go to the next one. Small steps. Otherwise you can feel confuse.

but it is really worth it

I can recommend to start with https://github.com/bhauman/figwheel-main-template use lein or clj. Whatever is easier for you. Later you can easy change it.

It is good solution. When you will learn how it works, then you can make next choices.

But please consider I have years of experience with clj / cljs, so I can be not the best guy to recommend solutions for somebody who start with it now.

I don’t remember how it was.

I can only recommend tools which are my choice

thanks @kwladyka

goog.ui.Tooltip

@hoertlehner https://google.github.io/closure-library/api/goog.ui.Tooltip.html

@hoertlehner and I don’t seen any reason to start with re-frame or reagent unless you think you are going to have bunch of functionality

that is my thinking too.

keeping it simple and understandable

is fine

I got hiccup running client side,

That tooltip lib should do the trick

and I want to render a nice popup window.

It appears to me that google does only display a simple text.

I was searching for examples for at least 4 hours now, and it appears to me that there are not many people who do old-style jquery apps with clojurescript,

so perhaps it is the right thing to do to get started with re-frame, simply because this is what clojurescript community is focusing on.

@hoertlehner if you are looking for jQuery examples you are going to need to search for Javascript examples not ClojureScript examples

I was hoping that I can skip figuring out how the js interop works till when I am more familiar with clojurescript.

I thought that something as simple as popups,

would be covered by a 101 clojurescript course.

but not so.

hahahah

yeah it sounds like you are wanting things to easier than they actually are 😉

I am crazy 🙂

My goal was to be up and running with a produciton style data mining app in 3 days.

like the rest of us

all while learning a new language

yes of course.

and new tools

when one jumps into the water,

one has to jump.

otherwise one never learns.

heh but probably on the end you will use tools which I mentioned anyway. But maybe it will be good to realise why you want to use them 🙂

yeah that’s never my recommendation for learning ClojureScript

Yeah, I don’t have too much experience about teaching.

I still think folks should start at half speed with ClojureScript

start super simple

people approach ClojureScript like learning ruby or python

or Javascript

there are more moving peices, and some subtle things going on

and Front end programming is not for the faint of heart either

especially today

Probably everybody should find they own way. Everybody learning in different way. For example for me huge milestone for clj was this challanege https://github.com/kwladyka/chess-challenge . I was doing it about 3 months to really understand Clojure deeply.

I was choosing hard things to understand things very deeply. But I was decided 100% I am going into Clojure.

those kinds of problems really really help

its only data

there is no interop

its just algorithms

yes, but when you understand all puzzle around interop is not an issue then

so while you learn the algorithms you also are unconsciously learning the tooling environment

much more http://clojure.wladyka.eu/posts-output/2015-08-24-how-to-improve-algorithm-speed.html

bruce: In case you ever want to move your cubicle to a warm climate: I bought a little lake in mexico, if you want to hang out there for some time, you can stay there for free. http://www.ranchokalan.com

oh so you bought a lot there?

To figure out this way I had to try 100 other things to find right one

yes, I bought 2 lakes.

100 hectar.

nobody there.

no electricity, but sun is plenty, so with solar you are good to go.

Which country?

lake is drinking water quality.

mexico

near playa del carmen.

oh too far for me, but sounds super cool

I really love nature

@hoertlehner I could build a Dome there!

yes, this is what I meant.

I just confused dome with cubicle.

nature is really nice there.

Damn why most of clj people are from US

I guess you would need to adapt the dome a little bit,

because climate is hotter.

well I build other things

and material sourcing is different there

definitely.

but also easy to get certain things from us.

is it all friends who have bought in?

So far it is just me and 2 friends.

We saw the lake,

liked it.

and then started buying one lot after the next.

it just happened.

for mexicans a lake has no value

as most of them cannot swim.

do you own the whole thing?

I own 100 hectar

together with 2 friends.

1 hectar = 10000 squarmeter.

so we do have space.

well that’s fun

took us almost 3 years to get permissions though.

but ok...

Can I use require here instead?

webpack will be fine with it?

no cons about size of files or whatever?

no concerns about file size, but you’ll have to figure out how to deal with default imports. i think you do something like require("@material-ui/core/colors/green").default or something like that. the default import syntax is the only thing that is really different with import statements

with webpack this can actually affect the file size since their tree-shaking only works with import

its fine for the colors though since there is nothing to shake

hmm so conclusion is I have to use import to not affect size of js. Am I right?

it mostly depends on which libraries you use. require is mostly fine since you are probably not going to actually only import what you need

ie. import {a,b,c} from "something" vs import * as x from "something"

oh will it be ok only with default export?

but not with import {a,b,c} from "something"

that is what you mean by > their tree-shaking only works with import

require is basically import * as x from "something". so everything in "something" will end up in your build

with import {a,b,c} from "something" webpack can remove whatever else is defined besides a,b,c

window.React = require("react");
window.ReactDOM = require("react-dom");

// material-ui

window.MaterialUiStyles = {
    createMuiTheme: require("@material-ui/core/styles").createMuiTheme,
    MuiThemeProvider: require("@material-ui/core/styles").MuiThemeProvider
}

window.MaterialUiCore = {
    Grid: require("@material-ui/core/Grid").default,
    Paper: require("@material-ui/core/Paper").default,
    AppBar: require("@material-ui/core/AppBar").default,
    Toolbar: require("@material-ui/core/Toolbar").default,
    Typography: require("@material-ui/core/Typography").default,
    IconButton: require("@material-ui/core/IconButton").default,
    Button: require("@material-ui/core/Button").default,
    Drawer: require("@material-ui/core/Drawer").default,
    TextField: require("@material-ui/core/TextField").default
}

window.MaterialUiColors = {
    deepPurple: require("@material-ui/core/colors/deepPurple").default,
    green: require("@material-ui/core/colors/green").default,
    blue: require("@material-ui/core/colors/blue").default
}

window.MaterialUiIcons = {
    Menu: require("@material-ui/icons/Menu").default,
    AccountCircle: require("@material-ui/icons/AccountCircle").default,
    Terrain: require("@material-ui/icons/Terrain").default
}

What do you think about it? Especially about createMuiTheme: require("@material-ui/core/styles").createMuiTheme, ?

Is it as good as import {createMuiTheme, MuiThemeProvider} from "@material-ui/core/styles"?

I think it horrible and would use shadow-cljs 😉

no it is not

hah I like your honest 🙂

tree shaking only works with import

but honestly you'll have to test this for yourself. I don't follow the webpack development that closely

It looks horrible, but it is not so bad. Because now I can require [material-ui-core :as mui-core] instead of dozens of files. It is a little like a choice between require them in cljs or in webpack. This lines have to be written anyway.

to be fair 🙂

BTW fighweel-main has {:npm {:bundles {"dist/index_bundle.js" "src/js/index.js"}}} which mean developers have to care only about js import / require stuff in index.js. Do not have to update :foreign-libs and :provides. Just saying to share what I have learned about tooling around node deps.

But for sure shadow-cljs rules. It is super great tool.

#object[TypeError TypeError: cljs.env is undefined] utils$core$loaded_namespaces@http://localhost:3449/js/compiled/out/figwheel/client/utils.js line 174 > eval:3:263 @http://localhost:3449/js/compiled/out/figwheel/client/utils.js line 174 > eval:1:313 @http://localhost:3449/js/compiled/out/figwheel/client/utils.js line 174 > eval:1:276 @http://localhost:3449/js/compiled/out/figwheel/client/utils.js line 174 > eval:1:2 figwheel$client$utils$eval_helper@http://localhost:3449/js/compiled/out/figwheel/client/utils.js:174:8

Hmm. Maybe cljs.env is not automatically loaded for you. To make that utils.core namespace be correct, you could throw in a (:require cljs.env), but that makes me wonder if something else is wrong (It is hard to have a working REPL without that being loaded.)

it is bizarre.

even the required did not help

Interesting. Ignoring the user.cljs auto-loaded namespace, you should be able to require that macro from the REPL:

(require-macros '[utils.core :refer [loaded-namespaces]])

fuck. it is not working.

Really? This is just a simple macro that accesses some compiler internals 🙂 Is it in utils/core.clj file?

Here it is working in figwheel-main: https://gist.github.com/mfikes/fffbdb4aafe221b21cc0a9856923e7d9

yes in core.

I think I need to remove my clojure isntallation

and start from scratch somehow.

I guess I did not upgrade correctly to clojure 1.9

thanks mdikes!!

Interesting. I have no ideas regarding what could be broken.

Installing CLJS DevTools 0.9.0 and enabling features :formatters :hints :async util.cljs:176:55 Feature :formatters cannot be installed. Unsupported Javascript context: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0. util.cljs:237:13 CLJS DevTools: some custom formatters were not rendered. https://github.com/binaryage/cljs-devtools/blob/master/docs/faq.md#why-some-custom-formatters-were-not-rendered

This is what it tells me on firefox.

just warnings,

but perhaps related.

Yeah, I've got that too. I don't think that should matter

does it work if you just try the request directly in the js console? i.e. fetch("").then(r => r.json()).then(console.log);

Check if any plugins are doing fancy business too

noscript, etc

I just restarted firefox,

now all works.

how bizarre.

I have tried for sure 200 times today.

perhaps I had connected figweel too many times,

and at some time it blew something up.

using any js deps that polyfill fetch on ff? I've never seen figwheel cause that.

no nothing.

stupid question..

how do I convert the js object back to a clojure script object?

js->clj

this then does not use keywords,

but uses strings in the map.

(js->clj json-str :keywordize-keys true)

ahhh!

But be mindful that if the purpose of your function is to then immediately convert that back into js to be consumed by some js thing, doing the conversion back and forth could be less performant than just doing the thing on the js obj

this cool trick I couldnt find in the books I read.

thanks!

But, if you're taking that data and then storing it in an atom somewhere, to be operated on in some later context, then sure, you might as well convert it.

I am just doing a prototype.

so no performance issues.

But using the js in clojurescript is horrible.

Just pure js with async await,

agreed 🙂

is much nicer.

aye

In pure JS I use ramda,

and this allows me to do a query like that really simple and nice.

async/await is panning out pretty nicely for js. I much prefer reading js written with async/await

I had the naive assumption that clojurescript is would have an even better syntax.

After async/await idioms settle in the js world, I wouldn't be surprised if the CLJS world decides to bring in a native version. One problem is that async/await introduces a whole new function type to js. So integrating that with CLJ/Ss single function type would have to be done gingerly, if at all possible.

but the repl driven development is way better in clojurescript.

There's an async/await polyfill built on promises, so it could probably be made as a lib cljs now. One issue is that the CLJS crowd isn't yet fully sold on the method. So that's probably why no one has cared to build a lib for that yet.

even though javascript would have everything ready for repl driven evelopment,

Well, actually, somebody pretty much did build one

I havent managed to do so.

https://github.com/leonoel/cloroutine

So, if you really want the slick syntax, you can have it

cool!

I have to study that!

If you take a look at the clojureverse thread linked to in that library, the point that I and other tried to make is that native async/await is about more than just syntax: its about better stack traces, better tooling, and using the much more solid and bug free implementations provided by the larger js communities.

There’s a reason why js people stayed away from it until it was available natively: the polyfill involves the same state-machine transformation that the go macro uses, which is very hard to debug when things go wrong.

The other point I tried to make is that this isn’t a “trendy” javascriptism--it wasn’t even invented by javascript and it has been ported to many major languages now.

@U8ES68TGX I still have problems sometimes with exceptions in async / await. Even with bluebird and all logging on, there are still some instances where it goes very wrong. This is my main issue I haave with async / await pipelines.

@U8ES68TGX I'd love to see a full proposal on what bringing async/await into cljs proper would look like

While preserving cljs's function semantics

@john yea i don’t know what else beyond shaun’s proposal would be needed. i’m not familiar with cljs internals

the only implementation issue anybody raised is the way the compiler creates lexical scopes, but shaun identified the way to change code generation and which forms would need to change

@hoertlehner i imagine that is so, but try your hand at core.async for a while and you’ll soon appreciate how sophisticated js async tools are

@U8ES68TGX ah, I didn't see that one before. Nice

hmm, seems to me, this proposal would make a lot of cljs code a lot less portable to clj

If that proposal could be converted to use clojure's promise semantics, where you await something by derefing it, that might be more portable.

OTOH, we wouldn't want the semantics to be too divergent either. The same blocking and synchronization semantics should hold between both languages, at least when in a single threaded mode.

Otherwise you've got greater divergence between languages for how state is transformed

My preferred solution is to bring "proper" blocking semantics to cljs using webworkers as threads, so we can preserve clojure semantics proper

i’m one of those weird people that actually likes async programming and would like to see cljs embrace it

But there's other proposals in the JS world that could bring in proper multi-threading anyway. So CLJS could just wait for that later standard and then just port clojure's proper parallelism semantics over that.

well for people like me that are actually building profit-oriented businesses on cljs right now, this exercise is not academic

but i don’t have time to do it myself so i can’t really complain

I make money on cljs too. But I came from clojure, not js.

So perhaps I'm more biased on preserving cljs's clojureyness

right and i think you’re in the majority. cljs is (largely) a tool for java programmers who don’t really like or appreciate javascript

(imo)

That's true to an extent

But you've got to really appreciate what clojure does for the java world, to appreciate why we want to preserve those idioms in js. Some of them don't appear to pay off at the moment, but I assure you, once multi-threading in js becomes a more common thing, CLJS will be your secret weapon.

well it’ll be 5 years at least so i won’t hold my breath 🙂

eh, I'd give it 2 years

this is out there now https://github.com/mbasso/wasm-worker

With SharedArrayBuffers, js devs can can start mucking around in mutable, shared state parallelism right now

2 years until we have sufficient browser adoption to build a business on it? i’d be surprised but maybe i’ll be wrong

All the tech is already adopted. It'll just be 2 years before js lib authors provide parallel idioms to exploit the tech that is available.

All the browsers now have SABs

frontend development needs to be massively simplified.

You can hack some 15 year old winforms app together really fast,

and web frontend takes 2x or 5x the amoutn of work.

sure, there are some additional problems,

but they are mostly the same,