Fork me on GitHub
#clojure-uk
<
2018-04-06
>
maleghast00:04:42

Hello there - sorry I was suddenly not there..

maleghast00:04:59

But I am back again - I am assuming only @seancorfield is around still if anyone..?

seancorfield00:04:17

Yeah, it's 5:30pm here.

seancorfield00:04:35

I'm in and out doing chores since it's trash and recycling night...

seancorfield00:04:40

@maleghast Seems like you're not here again! 😆

maleghast00:04:44

I am here! Just had a heart-stopping error moment

maleghast00:04:10

I tried to add react-datepicker to my project with CLJSJS and it KILLED it... 😞

maleghast00:04:27

So I pulled it out, and on restart my whole app was b0rk3d

maleghast00:04:02

Anyway, it was a parentheses fuckup on my part - Occam's Razor is very helpful in terms of a tool to help one stay calm...

maleghast00:04:33

SO anyway @seancorfield, I was going to ask you if you have a Reagent-friendly date-picker that you can / would recommend.

maleghast00:04:42

I am using the "new" version of juxt/edge as my framework / starting point, so I am not 100% comfortable yet with the way that works - it's all clojure.tools and deps.edn and classpaths and so forth...

maleghast00:04:21

I raise this as starting up the app in development mode after adding cljsjs.datepicker as a dependency seemed__ to pull in its deps (version specific React, moment and something else...), but the error message I got along with my complete app failure was something to do with the react-dom dependency not being fulfilled / available. 😞

maleghast00:04:00

So, if you know of a good candidate for a Reagent-friendly date-picker that I can "just use" I would be greatly in thy debt 😉

seancorfield00:04:11

I don't do any cljs / front end work, sorry.

seancorfield00:04:48

We tried cljs several years ago, decided it wasn't ready for prime time, and built our new front end in JS with React.js/Immutable.js/Redux/etc

seancorfield00:04:00

We have a JS team and we have a Clojure team.

seancorfield00:04:54

We might try cljs again at some point, but from watching the beginners struggling with all sorts of cljs tooling issues, I suspect it will be some while before we even consider trying it again.

seancorfield00:04:40

And the sort of problem you describe @maleghast is exactly why we don't want to go down the cljs path!

seancorfield00:04:13

As for date-pickers. We've tried a lot in JS/React.js and they all seem to suck. For some reason, no one seems to be able to get that one right 😞

maleghast01:04:29

@seancorfield - Thanks anyway 🙂

maleghast01:04:11

I am trying out AirBnB's one at the moment courtesy of CLJSJS and it's not exactly "working"

maleghast01:04:33

Going to try one more before I go to bed...

mccraigmccraig06:04:55

@maleghast we use the platform native date-pickers - we don't care so much about the web as a target, and android & ios both have half-decent native date-pickers built in

👍 8
guy08:04:18

Morning!

jonpither08:04:36

@seancorfield I don't envy having two different teams for JS vs server-side though, I think that leads to a philosophical tug of war for ownership of the codebase, increased integration overhead, and a less optimised interface between the two subsystems.

seancorfield16:04:56

We have a very clearly defined REST API and separate JIRA projects for front end and back end. We have daily cross-team standups, and we use Slack heavily to discuss touch points between the teams. Kevin (hiredman) and I own the Clojure codebase on the back end, Aaron and Paul own the JS codebase on the front end. We run deployments on different schedules. It all works pretty well.

jonpither16:04:28

Sounds great communication.. nice. My reticience with the model is also around agility, i.e. to be able to evolve towards things like server sent events & graphql.. and not get stuck on one particular model. Trial and error can be harder when the work is split across teams.

seancorfield16:04:54

Funnily enough we're using GraphQL in our latest project and both teams seem happy about that. We also discuss the possibility of the front end team skilling up in ClojureScript from time to time but we still feel tooling isn't really there yet.

👍 4
seancorfield16:04:27

We've been fairly pleased with how agile we can be about changing processes and technology. We've completely rev'd the REST API over time -- we deprecate an endpoint and open a front end ticket for them to switch to the new endpoint, and when that's in production we just clean up behind ourselves.

jonpither16:04:17

Sounds a lovely, mature team

jonpither16:04:45

Sorry for the split chat, Im still grokking slack threads

seancorfield16:04:53

Heh, well, I'm not sure we're all that "mature", especially in terms of process, but we constantly strive to "do better" 🙂

jonpither08:04:07

but your experience may well be a lot better 🙂

maleghast09:04:06

@jonpither - I expect that what you lay out above may well be the downside(s). I really like the tight mental integration between Clojure on the back-end and ClojureScript on the front end, but these little teething issues are the negative pay-off for sure. TLDR; nothing is perfect 😉

Rachel Westmacott09:04:11

@maleghast this may sound dumb (and forgive me if you’ve already tried this) but have you tried a hard refresh in the browser? I’ve had some crazy looking issues doing CLJS when changing dependencies that turned out to be completely solved once the browser stopped caching old versions of bits of code.

Rachel Westmacott09:04:47

also if you get a good date picker working then please let me know, because the browser one’s are lousy and I haven’t put time into investigating a better solution yet.

maleghast09:04:58

Thanks @peterwestmacott - I know what you mean, and yes I did a lot of cache clearing and "build cleaning" but in the end I culd not get react-datepicker working at all.

maleghast09:04:17

I will indeed let you know if I figure out a good one to use.

👍 4
guy09:04:29

If you are using re-frame you could check out re-com, (i think you might already know about it actually :thinking_face: ). Or you could see how re-com does it’s date pickers and maybe emulate it?

guy09:04:36

let me do a quick google

guy09:04:33

is what i was thinking about

guy09:04:05

but yeah that might be useful to you?

maleghast09:04:42

Thanks @guy - looking now, but also on phone

guy09:04:48

sure sure

maleghast11:04:27

@guy - and directly after I got in the car to run an errand and now I am working from the business hub in Aberfoyle, so now I will have a look... 😉

dominicm11:04:34

Driving to Edinburgh today

dominicm11:04:37

Long drive

🚙 8
saltire 8
maleghast11:04:05

@dominicm - Work or pleasure?

maleghast11:04:17

@guy - I think__ that I can just drop this in and get going again - my app is / can be restricted browser audience, so the compatibility issues don't concern me. I am not using re-frame (yet) but the docs are pretty clear that I don't need to.

👍 4
maleghast11:04:54

I will let you know how I get on...

guy12:04:05

please do!

dominicm12:04:58

we're going to the zoo and dungeons and something else

🎉 12
saltire 4
mario-star 4
parrot 4
maleghast12:04:56

I am, of course, wrapped up in family things and then off to London on Sunday, plus you'll not be wanting random geeks trip-bombing your getwaway anyway, I don't doubt...

dominicm15:04:59

I wouldn't mind at all, but my girlfriend has other plans 🤓

🏩 4
😁 4
maleghast12:04:06

Do let me know next time you are up here for work though.

yogidevbear12:04:17

A little nippy, but very nice

maleghast13:04:02

Lovely! Where are you @yogidevbear

yogidevbear13:04:05

Lake Windermere

❤️ 12
maleghast13:04:04

I ❤️ the Lakes

maleghast13:04:42

I spent a good deal of my childhood and youth in and around Windermere / Grasmere / Buttermere / Keswick and Borrowdale

yogidevbear16:04:17

First time we've been here. It's absolutely stunning 🙂

seancorfield16:04:56

We have a very clearly defined REST API and separate JIRA projects for front end and back end. We have daily cross-team standups, and we use Slack heavily to discuss touch points between the teams. Kevin (hiredman) and I own the Clojure codebase on the back end, Aaron and Paul own the JS codebase on the front end. We run deployments on different schedules. It all works pretty well.

jonpither16:04:28

Sounds great communication.. nice. My reticience with the model is also around agility, i.e. to be able to evolve towards things like server sent events & graphql.. and not get stuck on one particular model. Trial and error can be harder when the work is split across teams.

jonpither16:04:23

The counter argument to my point is that stability and standards are good, and made manifest in this setup.

seancorfield16:04:56

Forcing everyone to have all the knowledge written down has many benefits. Also, automating as much as possible. We have scripts to stand up new dev environments, as well as copious documentation on devops stuff as well as architecture of various things (including database schemas).

seancorfield16:04:18

@jonpither I think some of this is worthy of the main channel, not just a thread.

👍 8
jonpither16:04:29

Fullstack, single teams feels less risky. But the risk really only applies to places where constructive communication is made difficult

seancorfield17:04:19

I'm used to working in places where a "product" is often distributed across several small teams and each team owns a distinct "part" of the whole, so it doesn't seem a strange way to work to me -- and we have plenty of cross-team communication. But I can see how that could be a problem for some companies.