Comments (8)
This is one of the first things that I made a utility function for when starting with Fusion, and would be a great addition.
Being part of the public namespace / main module exports is something I wouldn't be a fan of, however. I like how rocket.rs does it, splitting main functionality and utility into rocket
and rocket_contrib
, with the latter containing utilities that most if not all large scale projects would use. This would also give users the choice to implement those said utilities themselves, or simply use a different variant of them, without polluting the main modules namespace.
Another useful utility function that I've been using with Fusion, which functions similar to the proposed makeState
, could be something like unwrapState
:
local function unwrapState(stateOrValue, registerAsDependency)
if stateOrValue is a state then
return stateOrValue:get(registerAsDependency)
end
return stateOrValue
end
from fusion.
I would argue that it's better to separate them for optimization sake.
Do you have benchmarks to show that a function like this poses any performance issue? Optimisation should not a primary concern until it's proven to be a problem with data.
In my mind it's much more important that developers have a good experience with Fusion than it is to always run the most optimal code path theoretically possible, though of course this is not an excuse to write horribly slow code.
This is completely unnecessary for constants, and would just result in us creating a lot of unnecessary objects. (Think creating an Observer object for every single property in the entirety of someone's UI code). For that reason I don't think this is viable long-term.
This would not be used in such a fashion. For one, this is a user-facing utility, not something for use inside Fusion itself. Secondly, it's not mandated to be used, so where performance is needed you can manually handle both cases. Thirdly, most uses for statify would be when components are processing custom props - which is largely limited to one-offs - and not used for every state object. Fourthly, the overhead is entirely at create time - constant-value state objects are completely weightless in terms of run time performance due to the push nature of the reactive graph.
from fusion.
The optimization basis was specifically in reference to memory usage, rather than speed.
That being said, I misunderstood what you meant by this, and thought you were specifically referring to what we were doing internally. As a result all I can say is disregard what I said... totally my fault.
from fusion.
I've so far identified three different solutions to this problem, which may not necessarily be the same as the solution proposed here.
- a function that transforms constants into state, but leaves state alone - meaning you can operate on constants just like they're state (this is what
makeState
is proposed to do) - a function that, given a constant, returns it; but given a state, returns the value of the state
- a function that wraps your component functions, automatically turning constants in your props into states
Some pseudocode examples:
local const = "const"
local state = Value("state")
-- option 1
local function makeState(x)
return if x is state then x else { get = function() return x end }
end
local function process(x)
print(x:get())
end
process(state) -- prints "state"
process(makeState(const)) -- prints "const"
-- option 2
local function get(x)
return if x is state then x:get() else x
end
local function process(x)
print(get(x))
end
process(state) -- prints "state"
process(const) -- prints "const"
-- option 3
local function wrap(component)
return function(props)
local realProps = {}
for key, value in pairs(props) do
realProps[key] = makeState(value)
end
return component(realProps)
end
end
local component = wrap(function(props)
print(props.value:get())
end)
-- prints "state"
component {
value = state
}
-- prints "const"
component {
value = const
}
I'm personally a huge fan of how option 2 doesn't require transforming variables or constructing objects, but it also means we can't use OOP notation. Perhaps we should be reconsidering the OOP syntax of state objects entirely? We're already moving away from metatable-based OOP, which would make self
useless to us.
from fusion.
This has been formalised as the unwrap()
function, which is currently slated for Fusion v0.3, so deferring to the Fusion v0.3 project board as such.
from fusion.
Still a bit confused on how we want this implemented. Do we want this to be Fusion.Statify(state | constant)
or do you want to add something like what @filiptibell said and create something like fusion_contrib
separate from Fusion? (and implement it there)
If we want the latter, do we want:
a) To implement it into the main fusion program (i.e. do Fusion.contrib.XYZ
where "XYZ" is just some utility that most people would use.
b) To implement it into a separate organization, and users can add them manually or via wally by doing something like ``XYZ = "fusion_contrib/xyz@VERSION" Edit: this is discussed in #40
Once I get some feedback on how we want this implemented I'll work on getting it added.
Edit: After diving more into the Fusion source code, I now understand what you mean when you say that you want the ability to Statify constants. To that end, I would argue that while this might improve the programming experience a little bit (at first the separation of various things into states and constants was a bit confusing and led to a few bugs in my early contribution process), I would argue that it's better to separate them for optimization sake. Though, that's just my immediate thought.
For instance, take the New.lua
file, you see something like this under "Properties bound to state":
local disconnect = Observer(value):onChange(function()
if ref.instance == nil then
if ENABLE_EXPERIMENTAL_GC_MODE then
if conn.Connected then
warn("ref is nil and instance is around!!!")
else
print("ref is nil, but instance was destroyed")
end
end
return
end
Scheduler.enqueueProperty(ref.instance, key, value:get(false))
end)
table.insert(cleanupTasks, disconnect)
This is completely unnecessary for constants, and would just result in us creating a lot of unnecessary objects. (Think creating an Observer object for every single property in the entirety of someone's UI code). For that reason I don't think this is viable long-term.
If anyone thinks otherwise feel free to let me know!
from fusion.
So I came up with this stupid idea. (But I'm still going to say it 🙂)
What if all data has a :get function. This doesn't mean it's a state object, more like a prop object. The prop object won't update. In the new function will prop just behave like some data.
from fusion.
In line with the motives behind #159 and #168, it might be worth considering an alternative name such as peek
or once
from fusion.
Related Issues (20)
- Observer should allow for multiple state objects at once HOT 3
- Typechecking capabilities are dramatically reduced in v0.3 HOT 1
- Should Value:set with force also trigger Computed onChange? HOT 1
- ForValues is not passing 'use' - only value is being passed on the first argument HOT 1
- Fusion for general Lua(u) environments HOT 4
- Support for Roact-like/Class-based components HOT 4
- Allow the Value type to specify what it can be set to HOT 1
- OnChange usage example is the same as the example for OnEvent
- Generalised value destruction HOT 16
- New state objects downstream from in-progress updates see inconsistent dependencies HOT 16
- NaN values break springs HOT 1
- Error boundaries HOT 1
- Look into fuzzing as part of our testing suite
- Add explanations and breakdowns of example place files
- Spring/Tween flickering with hydrated reference HOT 2
- Seems that Fusion 0.3 rbxm file is marked as 0.2 HOT 2
- Add unit tests for NaN self-similarity
- Computed does not capture dependency when Value created inside the callback HOT 2
- Fusion.Tween does not catch state update in certain cases
- Frozen tables should use reference equality
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.