The bug is passing string keys into business logic and not that the business logic expected atom keys, but you’re trying to change the latter instead of the first problem. User input (most often string keyed maps) should only ever land at a place where it’s Ecto.Changeset.cast or otherwise converted to an internal data structure. I would even say modifying those maps (e.g. add something to it) before “casting” to be a smell.
The other place for string keyed maps is if you need keys, which are user defined. But then your whole business logic needs to work with just string keys, because you never want to convert arbitrary user provided keys to atoms.
we’ll see. I tried to make it clear up front I wasn’t in love with and didn’t really expect much of anyone else to be either, but wanted to provoke some discussion and hopefully be pointed to some concrete, non-abstract pieces of advice or prior art dealing with the kinds of things I see in my production code base better/differently… When I look around at a few open source Phoenix apps I still see a fair amount of raw strings in their controllers, and I think there has to be a better way is all.
