Comments (4)
Proposed implementations
from fusion.
I'd prefer to avoid metatables if possible - I don't suspect they're necessary here.
from fusion.
Would having the methods for tables be acceptable?
from fusion.
I'm generally doubtful that this would be a good addition to the API. I did experiment with this kind of thing previously in a much earlier prototype, however it tended to make code a lot more confusing as state objects and constant values would be much easier to mix up by accident.
For example:
local constant = 25
local state = State(10)
local target = State()
target:set(constant + 2) -- just a regular addition
target:set(state + 25) -- this could implicitly run other code, register dependencies and other magic!
My general approach with the design of Fusion's API is that objects should look the way they behave. If you're using function call syntax, the thing you're calling should be a function. If you're using table indexing syntax, the thing you're indexing should be a table. That sort of thing.
I usually find that mixing up the syntax introduces unintuitive and hard to track bugs and performance issues. For example, if you're indexing something that looks like a table, you might not expect it to go run some code elsewhere, and so you could make things laggy if you did that too often.
To cover every metatable case, it would also require the addition of a notable amount of code to the Fusion codebase. That could would have to be unit tested, benchmarked and maintained.
Finally, I don't really see how this would benefit users greatly. As I mentioned in another issue (#12 (comment)):
Generally, when I propose a new API or evaluate a suggestion for an API, I look to these points to see whether it's worth adding:
- Does it allow the expression of imperative code in a more declarative style?
- Does it help avoid suboptimal code and provide useful optimisation by default, such as caching or lazy evaluation?
- Does it allow the library to handle certain parts of code that are very easy to mess up and introduce bugs into?
- Does it make code that isn't currently self evident easier to read?
These aren't strict points, but rather points for consideration. This is roughly the thought process I follow to try and disambiguate between 'kitchen sink' APIs and stuff that would generally be useful for developers to leverage.
The existing way of doing things seems perfectly clear and easy to read, to my eyes at least:
counter:set(counter:get() + 1)
Especially considering all of the above points, I don't think there's much utility in shortening it:
counter:set(counter + 1)
In addition, I see a possibly competing use case where you might also want to use metamethods - when deriving computed objects from state objects. For example:
-- the current way of doing things
local numCoins = State(50)
local ui = New "TextLabel" {
Text = Computed(function()
return "You have " .. numCoins:get() .. " coins."
end)
}
-- your syntax, where metamethods implicitly cast the state object to the value it stores
local numCoins = State(50)
local ui = New "TextLabel" {
Text = Computed(function()
return "You have " .. numCoins .. " coins."
end)
}
-- a competing syntax, where metamethods implicitly construct computed objects
local numCoins = State(50)
local ui = New "TextLabel" {
Text = "You have " .. numCoins .. " coins."
}
The way that I see things, the last two examples are unclear as to what exactly is going on. The creation and manipulation of state and computed objects are masked. Only in the first example is it clear that we're constructing a computed object that gets the value of the state object and manipulates it.
For these reasons, I don't think it's worth pursuing this feature request.
from fusion.
Related Issues (20)
- Fusion.Children should parent things in batching order HOT 7
- Allow T everywhere we publicly accept StateObject<T> HOT 1
- Dissolve state objects that don't deal with state HOT 4
- Rename CanBeState<T> to be more concise HOT 7
- Dealing with re-entrant updates HOT 2
- Introduce a more efficient connector between state and data model properties
- Heuristic memoisation for state objects HOT 1
- Add debugging protocol for non-invasive inspection
- Change design of Observer to allow pooling listeners HOT 1
- Reuse scopes from primitive computed objects HOT 3
- Test what an ideal scope pool size is HOT 1
- Integrate under-documented APIs into tutorials
- Explore safer interpretations of `deriveScope` HOT 1
- Spring setters don't work immediately after construction
- Memoise special key generation functions
- Poor typechecking for use functions with UsedAs<T>
- Derive scopes with additional methods HOT 2
- Standard set of reactive graph shapes for testing HOT 1
- Write tutorial for `Safe` expressions
- Broken default props link (still uses .lua)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fusion.