Fork me on GitHub
#figwheel-main
<
2019-02-18
>
dominicm11:02:10

are extra mains compatible with using your own server? It would seem not to me. I'm using a custom asset path, which causes figwheel to be unable to server the js.

bhauman16:02:25

@dominicm extra mains will work with your own server, but you will need to create the landing page

dominicm16:02:03

Okay, makes sense. I had hoped to use figwheel as my auxiliary server for all dev tooling, but that seems less possible now.

bhauman16:02:31

not sure what that means??

dominicm16:02:02

I was going to put a bunch of random builds onto there, even some which were hard coded pages, just as a permanent server to host things.

dominicm16:02:09

Out of curiosity (and I think the answer is very) how hard would it be to bring figwheel's websocket server into my own server?

bhauman16:02:09

you wanted figwheel to server all tests devcards, etc

dominicm16:02:43

yeah. I even had some schemes involving it having a bookmarking "service" and similar.

bhauman16:02:59

yes the state of websockets in java is ugly right.

bhauman16:02:56

of course with some abstraction, we could make it easier but you will be coding the websocket endpoint for certain

bhauman16:02:17

but why not middleware in the figwheel server?

bhauman16:02:07

there’s nothing you can’t do via that route

dominicm16:02:45

coding the websocket part is fine by me, aleph's interface for this is rather nice.

dominicm16:02:48

No particular reason 🙂 that's probably the better option really. If it was easy enough, then it's nice to have only 1 port open rather than 2.

dominicm16:02:30

One factor is that I might want this to work with figwheel-sidecar and/or shadow, so my current thinking was a third server, which wasn't something I preferred.

bhauman16:02:12

yeah that makes sense

bhauman16:02:05

if ring had a websocket interface that was supported by the dominant webservers that would be fantastic

bhauman16:02:24

then this would all be trivial

dominicm16:02:41

I suppose a third-party ring extension could work...

dominicm17:02:51

(I should probably note that this is all in the context of our application framework rather than a single project - hence things like shadow support)

bhauman17:02:19

yep I get that

dominicm17:02:59

Anyway, thanks 🙂 figwheel-main has been really great in Edge. I've moved a few of our projects over from figwheel-sidecar, and things are generally much smoother. We're just starting to experiment with devcards, auto-testing, etc.

dominicm17:02:50

I'm wanting to do an "auto-mains listing" which links you to the auto-testing, devcards, etc. when you do (go), so figuring out where that will live is important.

dpsutton17:02:00

I've coined the term "bruce shop" for a figwheel/devcards/cljs-test-display shop

dominicm17:02:50

We were able to impress a client who buzzword tests using cljs-test-display. The tests were mostly useless, but the client loved the UI.

😆 10
dominicm17:02:59

Hmm, hard to convey what I'm getting at there in a concise way. The client likes tests, but doesn't know when tests are useless and burdensome, so they just want to see lots of tests.

bhauman17:02:59

just deployed 0.2.1-SNAPSHOT which fixes warnings that started showing up with the recent compiler changes

👍 15