using alternate hiccup syntax for defining dom about fn-fx HOT 10 CLOSED

okay it's cool. I figured it out.

from fn-fx.

I started working on supporting nested properties (https://github.com/fn-fx/fn-fx/tree/nested_properties), I have a solution which kind of resembles hiccup, but I'm not very happy with it. I'm looking now for another solution. Have you done something in the direction of supporting hiccup syntax?

from fn-fx.

from fn-fx.

What's the reason for this change? Where would be the differences to what we have right now?

from fn-fx.

from fn-fx.

from fn-fx.

What I needed was the ability to create encapsulated components with local state and external hooks, something similar to react.

from fn-fx.

from fn-fx.

To be honest I don't like it. :) I feel like it's adding a different abstraction layer on top of JavaFX.

With regard to local state, I worked with React and stateful components are tricky. The good thing is they encapsulate something and allows you to build more sophisticated building blocks. The problem is you sometimes find out later that you need that piece of information which was initially hidden as local state. In clojurescript, Om's solution is to keep the entire state in a single global atom and declare for each component what data it needs in form of a query, and Reagent works with binding atoms to places where the data is needed.

I don't think the hiccup syntax is what's missing from fn-fx, and it's certainly not related to state management. (I don't quite like that in the current syntax instantiating a component uses dash-notation, while the component itself is CamelCase, but that's rather a cosmetic thing). It may be nice, maybe more familiar, but I think it's more of a surface thing.

I would rather change the event system. It may scale, as @halgari says, but I don't like the way it's coupled with the state: you always get the entire state as a function argument, and must return the updated state. I feel that here is where a limitation starts to kick in. I would rather let listeners be simple functions and manage state differently, maybe by adopting one of the models from the Clojurescript world.

from fn-fx.

I just stumbled upon a limitation of the event handling in fn-fx: key events in javafx are handled by properties whose values are event handlers. This means the :listen/on-key-pressed will not work, as it registers a listener to the onKeyPressed property, whereas we need to set the value of the property to the listener function.

from fn-fx.