Борьба с FRP
Я читал о FRP и был очень взволнован. Это выглядит великолепно, так что вы можете написать больше высокоуровневого кода, и все будет более легко компоноваться и т. Д.
Затем я попытался переписать свою маленькую игру с несколькими сотнями слоков от простого js до Бэкона.
И я обнаружил, что вместо написания высокоуровневого логического кода, я на самом деле опередил Bacon.js и его приверженность принципам.
Я сталкиваюсь с некоторой головной болью, которая в основном мешает чистому коду
.take(1)
Вместо того, чтобы получать значение, я должен создавать некрасивые конструкции.
Круговые зависимостиИногда они должны быть по логике. Но реализовать его в FRP страшно
Активное состояниеДаже создатель bacon.js имеетпроблемы с этим.
В качестве примера здесь приведен код, демонстрирующий проблему:
Задача не позволить двум игрокам оставаться на одном месте
Реализуется с помощью bacon.js
http://jsbin.com/zopiyarugu/2/edit?js,console
function add(a) {return function(b){return a + b}}
function nEq(a) {return function(b){return a !== b}}
function eq(a) {return function(b){return a === b}}
function always(val) {return function(){return val}}
function id(a){return a}
var Player = function(players, movement, initPos){
var me = {};
me.position = movement
.flatMap(function(val){
return me.position
.take(1)
.map(add(val))
})
.flatMap(function(posFuture){
var otherPlayerPositions = players
.filter(nEq(me))
.map(function(player){return player.position.take(1)})
return Bacon
.combineAsArray(otherPlayerPositions)
.map(function(positions){
return !positions.some(eq(posFuture));
})
.filter(id)
.map(always(posFuture))
})
.log('player:' + initPos)
.toProperty(initPos);
return me;
}
var moveA = new Bacon.Bus();
var moveB = new Bacon.Bus();
var players = [];
players.push(new Player(players, moveA, 0));
players.push(new Player(players, moveB, 10));
moveA.push(4);
moveB.push(-4);
moveA.push(1);
moveB.push(-1);
moveB.push(-1);
moveB.push(-1);
moveA.push(1);
moveA.push(-1);
moveB.push(-1);
То, что я хочу продемонстрировать, это:
me.positions
иметь зависимость самостоятельноНелегко понять этот код.Вот это обязательная реализация. И это выглядит намного проще для понимания. Я провел гораздо больше времени с реализацией бекона. И в результате я не уверен, что это будет работать, как ожидалось.Мой вопрос:Вероятно, я скучаю по чему-то фундаментальному. Может быть, моя реализация не так в стиле FRP?
Может быть, этот код выглядит хорошо, и он просто не привык к новому стилю кодирования?
Или это общеизвестные проблемы, и мне лучше всего выбирать зло? Так что проблемы с FRP, как описано, или проблемы с ООП.