Fork me on GitHub
#hoplon
<
2016-12-26
>
thedavidmeister02:12:59

@candera nah, no web workers at all

thedavidmeister02:12:13

no errors in the console

thedavidmeister02:12:41

what should i see in the console/ui to indicate that something has happened due to reload?

candera02:12:11

When I was seeing reload failures, there were console errors about there not being a window object.

thedavidmeister02:12:41

nah, i don’t think its even getting to that point

mynomoto11:12:25

@micha about routes, is checking if the route is the right one before using route params the way to go? I found that problem at https://github.com/mynomoto/github-client/blob/master/src/github_client/page/exploration.cljs#L15

mynomoto11:12:06

Most when used in that page are because you can be on other routes and the param is nil in that case.

thedavidmeister14:12:32

@mynomoto i’m using bidi but i don’t re-use route-param keys across routes where it doesn’t mean the same thing

mynomoto15:12:20

@thedavidmeister that sound restricting. I almost cannot believe that I didn't had this problem before but guarding against not being in the current route is a bummer 😕

mynomoto15:12:56

I'm using silk for routes but it works almost the same as bidi so similar problems I guess.

micha15:12:36

i think that functions should be able to handle nils

micha15:12:04

that's generally how i handle that issue

mynomoto15:12:53

They can but I was hopping for something less cumbersome than checking if it is the right route or if the param is not nil on every place where I want to use it.

micha15:12:07

usually if the functions return nil when they get nil arguments it just stops propagation naturally

micha15:12:29

because then other functions return nil themselves etc

mynomoto15:12:29

Unless it causes a npe. In that case it was a keyword to get from a map and a string to run a regex on.

micha15:12:48

yeah that's why I'll make safe versions of functions that throw npe

micha15:12:39

lisp really doesn't need to ever throw npe

micha15:12:57

it's just when you do unguarded interop

mynomoto16:12:00

That probably should be a lib with a nil punning joke name 😛

mynomoto16:12:11

This solution has the advantage of not making code context aware as would check the right route would. Thanks.

micha16:12:05

you still have the when, but it's in a central place

mynomoto16:12:44

Less chances of forgetting it I think.

flyboarder19:12:36

@micha https://github.com/blog/2289-publishing-with-github-pages-now-as-easy-as-1-2-3 docs should be pretty easy now, aren't you already generating markdown files?

micha19:12:44

@flyboarder you mean for api docs?

micha19:12:01

seems better to me to have the api docs as part of the repo itself

micha19:12:05

rather than gh pages

micha19:12:11

that way it's properly versioned

flyboarder19:12:22

agreed, the new method is a docs folder

micha19:12:32

yeah that's what i do with boot

flyboarder19:12:41

that is generated into a page via md now

micha19:12:45

although i need to update that, i keep forgetting 🙂

micha19:12:57

my docgen thing doesn't work with cljs though, because it uses reflection on the live system

micha19:12:08

maybe the cljs repl could work though

micha19:12:23

my thing doesn't do static analysis of source files at all

micha19:12:38

it requires the namespace and then uses reflection on it

micha19:12:55

that allows you to get dynamically generated names as well

micha19:12:03

like functions created by macros, etc

micha19:12:47

and static analysis is too brittle to maintain

flyboarder19:12:22

would it be beneficial to organize core into smaller parts? It's starting to do a lot

flyboarder19:12:39

i dont know how much that helps with documentation though

micha19:12:30

i dont think we want to remove anything

micha19:12:35

cause breaking changes

micha19:12:46

but not adding more things to core seems like a good idea

flyboarder19:12:14

i was thinking more like the protocols and such, they dont need to be in there but the implementations do

flyboarder19:12:37

hoplon seems pretty complete right now

micha19:12:47

which protocols?

micha19:12:03

the defprotocol will determine the namespace of the protocol method when you call it

micha19:12:22

so i don't think we want to move any of those or it would break any code that uses a protocol method

flyboarder19:12:40

I think you can refer them still I was doing it in my mk! multi tests

flyboarder19:12:29

but it's not an issue so why bother right, im just thinking about ways to cleanup the namespace so documenting it makes sense