Split the Yesod Typeclass

[noinia]

Currently, the Yesod typeclass contains a fairly large amount of functions, some of which are disguised settings (appRoot, urlRenderOverride, authRoute, cleanPath, joinPath), and some of which very implementation oriented (pretty much everything producing something of type HandlerT, makeLogger, messageLoggerSourceSource, yessodMiddleWare etc). I would like to request splitting the Yesod Typeclass into two (or more?) separate classes, such that we can separate the settings from the implementation.

I'm currently working on a project in which the one big monolithic type class is an issue: I'm developing a client-server application; both are developed in haskell. For the server I'm using Yesod. I would like to use the type safe routing in the client as well: i.e. just produce values of the 'Route site' type that we give to a function that actually connects to the server. I want to separate the api into a separate package, on which both the client and server depend (so that the client does not have to depend on the entire implementation of the server). Essentially this api package contains the (generated) RenderRoute instance. However, I would also need access to the joinPath function, which is only provided in the Yesod typeclass. However, since this typeclass contains a lot of functions specific to a server implementation I cannot really move it to the api package.

Any thoughts on this?

[snoyberg]

I think this would be more simply achieved by having your shared package provide a function with the same type signature/behavior as joinPath from the Yesod typeclass.

[noinia]

I started with that, but that appeoach has two problems: 1) it has to code duplication, and (more importantly) 2) does not enforce that the paths that the client and server use are the same. (i.e. you would hope that the server implements the joinPath in the yesod class using the joinPath function provided by the shared package, but you cannot enforce it)

[snoyberg]

I don't see any code duplication; you would write joinPath = myJoinPath, which is pretty terse.

This kind of issue of different code paths is pretty common in Haskell. For example, with Applicative and Monad, you need to ensure that pure and return have the same behavior. This is expressed as typeclass laws. It may not be ideal, but I don't think the use case you're describing warrants breaking everyone's existing Yesod code, when a relatively painless alternative exists.

[snoyberg]

This is too large a breaking change to undergo, closing.