Fork me on GitHub
#shadow-cljs
<
2018-05-27
>
kwladyka08:05:13

Whatever I change content, page in browser reload without any errors, but content on page doesn’t change. I have to reload browser each time manually. Am I doing something wrong?

kwladyka08:05:37

(defn main-panel []
  [:div "foo"])

thheller08:05:22

@kwladyka you probably need an after-load callback to actually re-render?

kwladyka08:05:38

It was working in figwheel without additional re-render functions

thheller08:05:40

in figwheel it is called on-jsload I think

thheller08:05:53

I doubt that

thheller08:05:07

check you figwheel config

kwladyka08:05:53

oh…. true… I am sorry

kwladyka08:05:41

thank you again

kwladyka08:05:41

it works 🙂

kwladyka09:05:20

Is there a way to not write:

["@material-ui/core/Styles" :default Styles]
            ["@material-ui/core/AppBar" :default AppBar]
            ["@material-ui/core/Toolbar" :default Toolbar]
            ["@material-ui/core/Typography" :default Typography]
            ["@material-ui/core/Button" :default Button]
...

kwladyka09:05:17

[@material-ui/core/ :foo [Styles AppBar Toolbar]] or import all or …?

kwladyka09:05:25

It is not shadow-cljs question probably, but how to translate into cljs:

const styles = {
  root: {
    flexGrow: 1,
  },
};

function SimpleAppBar(props) {
  const { classes } = props;
  return (
    <div className={classes.root}>
      <AppBar position="static" color="default">
        <Toolbar>
          <Typography variant="title" color="inherit">
            Title
          </Typography>
        </Toolbar>
      </AppBar>
    </div>
  );
}

SimpleAppBar.propTypes = {
  classes: PropTypes.object.isRequired,
};

export default withStyles(styles)(SimpleAppBar);
while I am using reagent with hiccup.

thheller09:05:52

no idea. probably need to ask in #reagent

thheller11:05:28

in 2.3.27 I finally merged the :build-hooks stuff I had laying around since forever. should have done this way sooner but here it is now: https://shadow-cljs.github.io/docs/UsersGuide.html#build-hooks

thheller11:05:47

@mhuebert ^ might be interesting to you since I know you do a lot of custom clj-run stuff already

thheller11:05:26

@kurt-o-sys you also asked about generating an index.html for the build. :build-hooks could now do stuff like that.

mhuebert17:05:28

@thheller these build hooks are working great for my html- and css- file generation

mhuebert17:05:52

no longer any need to use clj-run

mhuebert17:05:19

I was wondering if any of the additional data from the build stage would be available, like the :info key that is part of the build log event (eg. to know which files have been compiled). Nevermind, found it in :shadow.build/build-info

mhuebert18:05:14

is the watched & changed file that triggers a build noted in the build state somewhere?

thheller19:05:15

@mhuebert doesn't the build-info contain all that?

mhuebert19:05:56

@thheller it has :compile-start, :timings, :modules, :sources, :compiled

mhuebert19:05:26

:compiled is the closest, but I didn’t see that it indicates which file changed

thheller19:05:13

:compiled is the set of resources that where recompiled

thheller19:05:28

:sources is the list of all sources in that build

thheller19:05:48

so for each :sources where :resource-id is contained in :compiled gives you the sources that were recompiled

thheller19:05:13

the "trigger" itself is not kept

thheller19:05:17

(->> sources
     (filter #(contains? compiled (:resource-id %)))
     ...)

mhuebert19:05:35

yeah, I was doing something like that in the client

active-namespaces (set (keys (:cljs.analyzer/namespaces @carton/compiler)))
compiled-namespaces (-> (:sources @bootstrap-env/index-ref)
                        (select-keys compiled)
                        (vals)
                        (->> (filter (comp active-namespaces :ns))))

thheller19:05:01

that works too

mhuebert19:05:14

then i used made a ring handler that serves arbitrary resources from the classpath and requested the original clj* files to eval directly via self-host

mhuebert19:05:32

i am still just experimenting, with what kind of dev experience might be nice when building selfhost-compatible things.

mhuebert19:05:37

this stuff is to allow for editing from intelliJ, with all changes going into a live environment in the browser

mhuebert19:05:57

metadata on vars determines how they are visualized

mhuebert19:05:18

so you can have a nice tree of all your namespaces, with various def’d things appearing in arbitrary/nice ways

mhuebert19:05:01

some things in common with devcards but more like a general namespace browser + ability to layer custom views where you want

thheller19:05:40

sounds cool but why self-host?

thheller19:05:47

hmm I guess you want maria-style? so cloud vs something running locally?

mhuebert19:05:53

not entirely sure. it could be an augmentation to a version of maria (or something like it) which runs locally, and is also updated from files, but you have the full compiler state on hand

mhuebert19:05:12

i was also looking at making a little API in the handler for exposing more things from the compiler-state,

mhuebert19:05:34

then one could do more with non-selfhost stuff

thheller19:05:42

I did a few tests with pathom for using graph queries to expose shadow-cljs internal data

thheller20:05:06

which could technically be used to let you query the entire cljs.analyzer state for whatever you'd need

thheller20:05:43

I do have plans myself for the shadow-cljs that would let you browser docs and such

thheller20:05:51

with a little eval window to try stuff directly

thheller20:05:10

I added http://localhost:9630/repl as the first basic test

mhuebert20:05:10

i have not looked at pathom before

thheller20:05:22

not related to the pathom/graph stuff

thheller20:05:37

just wanted to test accessing the REPL directly from the browser

mhuebert20:05:50

we will want some kind of namespace browser for maria eventually,

mhuebert20:05:16

and it would be very nice if the same thing could be used outside of selfhost

mhuebert20:05:24

pathom looks promising in that the same description of analyzer data could be resolved on the shadow side or in the browser, depending on which compiler-env you wanted to inspect

thheller20:05:21

yeah it made writing a few test queries really easy

mhuebert20:05:12

hmm is there a way to type into http://localhost:9630/repl

mhuebert20:05:28

oh nevermind i didn’t see the thing at the bottom

thheller20:05:32

codemirror with parinfer at the bottom

thheller20:05:34

shift+enter to eval

thheller20:05:04

extremely basic stuff. no history, no autocomplete, nothing useful really

mhuebert20:05:10

but the basic concept is there

mhuebert20:05:35

and could easily add some UI around evaluating useful things by clicking

thheller20:05:45

I will start building a proper UI eventually. just started with this to test some stuff

mhuebert20:05:31

is there a way to list builds?

thheller20:05:08

its just a clojure REPL

thheller20:05:12

(-> (shadow.cljs.devtools.config/load-cljs-edn) :builds keys)

mhuebert20:05:42

that’s what i was looking for

thheller20:05:50

should probably add a proper api method for that

thheller20:05:07

open a ticket for that if you need it