edn rendering can fail when rendering map with unsortable keys about devcards

[bhauman]

This is a problem. @pkobrien what do you think about rolling back the sorted-map stuff? This is an assumption we can't make.

Also I have been thinking about just using pprint. And dropping the edn rendering. I'm betting that pprint is probably a lot faster and more stable.

Unless we want to grow functionality into edn rendering like editing difference highlighting etc. But if that isn't going to happen pprint is probably a better fit.

[darwin]

@bhauman a side note: I'm rendering maps of different sizes. And sometimes devcards decides to render it as EDN (small maps?) and sometimes as code.

I tried to read sources, but I wasn't able to find the exact place where that decision is made. This part looks like the suspect, but I don't see any problem there:
https://github.com/bhauman/devcards/blob/master/src/devcards/core.cljs#L283-L296

I would like to force rendering to always be "as code" in my use-case. Here is the code for reference:
https://github.com/darwin/plastic/blob/b9f8e10d02ec6440df277700caa6a6861fd17c3e/cljs/src/devcards/plastic/devcards/util.cljs#L57

[bhauman]

There is no explicit forcing of rendering as code or data in the edn renderer. You may be seeing some flexbox layout effects? Hard to know from here. You certainly are banging on this code more than I have :)

[pkobrien]

I agree this is a problem. I guess I learned something about not assuming that all keys could be sorted. We certainly don't want Devcards to choke while displaying unsortable keys. I think the sorting should be rolled back. I also agree that you probably don't want to be in the business of having to maintain rendering logic so if pprint can be used that would be a good move.

[bhauman]

oh we didn't fix this yet