Comments (11)
Tags shouldn't be designed like Attributes. How would it even work in actual code? All keys need a value, so do we just have to set it to true in all cases because yes? Do we make the value a boolean which controls if it has that tag or not? It also looks a lot harder to guess what the value that we set it to means.
New "Frame" {
[Tag "MyTag"] = true
}
This looks incredibly awkward to read imo. In comparison to the original proposal,
New "Frame" {
[Tags] = {"MyTag"}
}
This looks way better in my eyes as we aren't pretending to store some magical value.
It also makes using states more pleasing on the eyes.
[Tag(tagName)] = true
vs [Tags] = {tagName}
from fusion.
Yeah this is the sort of thing I'm thinking about. We could do both perhaps, no reason not to.
This perhaps could inform the reactive tag APIs in #206
from fusion.
Since tags are unordered like properties, a possible alternative API:
New "Folder" {
[Tag "Foo"] = true,
[Tag "Bar"] = true,
}
Though this eliminates the possibility of binding a set of tags. On the other hand, this would be a good solution if binding sets of tags were expressly unwanted.
from fusion.
This is an interesting idea! I'm assuming this is talking about CollectionService tags?
from fusion.
I would go for the first option, having a tags symbol like children. On a similar note, this should probably be added for attributes too?
from fusion.
On a similar note, this should probably be added for attributes too?
Tracking that here: #1
from fusion.
The design of this API will probably be guided by #1
from fusion.
I think we'll go for Tags
syntax here, it seems more appropriate given there isn't really a pair of values. Thanks for the feedback.
from fusion.
I think we'll go for
Tags
syntax here, it seems more appropriate given there isn't really a pair of values. Thanks for the feedback.
Will any excess tags be removed automatically? Eg if Hydrate
ing an instance that already has a generic Weapon
tag, and wanting to add either Gun
or Knife
depending on state? What if Tags
is not specified, will that remove excess tags too? That creates the confusing option where adding something in the code actually ends up removing more things at runtime.
I think I've changed my earlier opinion and prefer the option of treating them like [Tag "A"] = bool
from fusion.
Regarding extraneous tags, Fusion would have to deliberately go out of its way to remove them, and that would be an unnecessary step from Fusion's PoV. To implement tag states, Fusion would just be making calls to AddTag and RemoveTag as needed to reconcile state changes. As long as a tag isn't involved in this state, then it would remain untouched.
Regarding the syntax, my original use-case only used tags as constants, so I don't really have a stake in either. But I can try to imagine scenarios that involve state objects. The Tags
syntax seems like it would be a lot easier to use in general.
local itemRelatedTags = Value({}::{string})
local weaponRelatedTags = Value({}::{string})
local sword = Sword {
[Tags] = {
itemRelatedTags,
weaponRelatedTags,
},
}
itemRelatedTags:set({"Durability", "Countable"}) -- sword gains Durability and Countable.
weaponRelatedTags:set({"Durability", "Damaging"}) -- sword gains Damaging.
itemRelatedTags:set({}) -- sword loses Countable.
weaponRelatedTags:set({}) -- sword loses Damaging.
Meanwhile, the same behavior with the Tag
syntax would be a lot more verbose:
local itemRelatedTags = Value({}::{[string]:true})
local weaponRelatedTags = Value({}::{[string]:true})
local sword = Sword {
[Tag "Durability"] = Computed(function(use)
return use(itemRelatedTags.Durability) or use(weaponRelatedTags.Durability)
end),
[Tag "Countable"] = Computed(function(use)
return use(itemRelatedTags.Countable)
end),
[Tag "Damaging"] = Computed(function(use)
return use(weaponRelatedTags.Damaging)
end),
}
itemRelatedTags:set({Durability=true, Countable=true})
weaponRelatedTags:set({Durability=true, Damaging=true})
itemRelatedTags:set({})
weaponRelatedTags:set({})
While awkward for this particular scenario, we're being much more deliberate about what tags are defined on the instance, which might be seen as a benefit in some situations.
I think it depends on the situation, and I'd wager that both syntaxes have their ideal use-cases. If I really had to pick a side, I'd be on team por-que-no-los-dos.
from fusion.
Both? Both. Both. Both is good.
But we'll divvy it up a bit; if we're adding Tags
, we should probably consider whether there are reasonable interpretations of Attributes
, Properties
, Events
, etc. There's already some demand for bulk property setting over in #137, so I think that's a valuable discussion.
So what I'll do is I'll limit the scope of this particular change to Tag
, and I'll broaden the scope of the other issue to encompass bulk setting as a general concept.
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.