Consider supporting ETH directly, or at least using an ERC777 ETH wrapper.

[MicahZoltu]

Problem

A big selling point of ETH is the lack of need of approvals. Requiring all pairs be token-token means that everyone always has to do approvals when using Uniswap which increases user friction.

Solution - Native ETH Exchanges

Do what Uniswap v1 did and always have ETH as a base. In order to support token-token pairs (which I still argue are a bad idea in general as it bifurcates liquidity, but it seems I have lost that battle), you could have two Uniswap exchange contracts one for token-token (like you have now) and one for token-eth. The factory can create either token-eth or token-token exchange based on inputs (or function being called) and the UI can trivially aggregate these two sets of contracts into a single UI. This would allow you to not have the code complexity that comes with trying to do branching inside of the exchanges based on denominating token vs ETH. You could reduce code duplication by using inheritance such that most of the business logic is inside a base contract (all the mathing and whatnot) while the derived contract would just have implementation code for the send function and receive function.

Solution - ERC777 ETH Wrapper

ERC777 supports approval-free transfers by way of wrappedEth.transfer(uniswap, amount, callbackData) where callbackData contains details of the attempted trade. The exchange would then execute the trade as normal, with the exception of not using msg.sender anywhere and instead use the from provided in the tokensReceived callback.

[NoahZinsmeister]

this is more of a router problem, also note that the router will include payable functions so that users can interact with WETH-ERC20 exchanges using ETH directly!