print(correctedData) --> {kills = 10, deaths = 0, xp = 0, abc = 30} 

abc should be 20

Currently, I find myself doing repeat task.wait() until Component.FromInstance() very often. It would be nice if we had a Component.WaitForInstance method that returned a promise.

An example: Component.WaitForInstance(instance, timeout):andThen(function (component) end)

.Started and .Stopped should fire when I call :Start and :Stop, respectively.

Should not fire if I call :Start and timer is already running; same with :Stop.

If you set the RenderPriority of a component, and have more than one component of the same type active at once, then removing the component will not reliable unregister the callback.

This, I believe is caused by _renderName being stored on self in StartComponent rather than component. This results in there being cases where two components can end up with the same _renderName which causes all but one of them not to unregister correctly when the component stops.

Currently, the Input Util does not contain any support for the gamepad input type. It would be useful to have this included so that we can more easily build cross-platform games without needing to use the native UserInputService

At the moment, it is difficult to learn a new util module because there are no examples showing us how to use them.

To solve this problem, it would be nice if every util module had a quick example of the main functionality

When dispatching SiloUtil.None in a combined silo, it does not remove the value from the state.

Single Silo:

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local Silo = require(ReplicatedStorage.Packages.Silo)
local SiloUtil = require(ReplicatedStorage.Packages._Index["[email protected]"].silo.Util)

local initialState = {
	myValue = 123,
}

local mySilo = Silo.new(initialState, {
	Set = function(state, action)
		state.myValue = action.value
	end,
})

mySilo:Watch(function(state)
	return state
end, function(objects)
	print(objects)
end)

task.wait(1)

print("Set Empty")
mySilo:Dispatch(mySilo.Actions.Set({
	value = SiloUtil.None
}))

Final Output: {}

Combined Silo:

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local Silo = require(ReplicatedStorage.Packages.Silo)
local SiloUtil = require(ReplicatedStorage.Packages._Index["[email protected]"].silo.Util)

local initialState = {
	myValue = 123,
}

local mySilo = Silo.new(initialState, {
	Set = function(state, action)
		state.myValue = action.value
	end,
})

local MAIN = Silo.combine({
	mySilo = mySilo,
})

MAIN:Watch(function(state)
	return state.mySilo
end, function(objects)
	print(objects)
end)

task.wait(1)

print("Set Empty")
MAIN:Dispatch(mySilo.Actions.Set({
	value = SiloUtil.None
}))

Final Output: {myValue = 123}
Expected output: {}

If you have a component that is destroyed before Start() finishes, Stop() is never called and the Heartbeat and other update functions are never unregistered.

This destruction can happen either by the object being destroyed, the tag being removed or the object being removed from the set of ancestors defined.

This requires Start to not immediately return.

The following code will trigger this bug in a fairly easy fashion, but there are a number of other ways this can happen - we've seen it where Start() is waiting for a Knit service to be available before continuing and having the object destroyed before it is.

function SomeComponent:Start()
    self.Instance:Destroy()
    RunService.Heartbeat:Wait()
end

I don't think it's unreasonable to say that Start should return immediately - but this should be documented if this is the case - and ideally detected if it isn't. Often this can be quite an invisible problem and can cause memory leaks. We only noticed this due to a fairly specific set of circumstances but I suspect it may occur invisibly for other users.

Alternatively, TryDeconstructComponent should be revised - perhaps it can wait for Start to complete - i.e. the system could track that a component is in the process of starting. This seems like the least-worst solution to this issue.

Troves accept threads that will be closed when the trove is cleaned up. However, if this thread is the currently-running thread or marked as the "normal" thread, then it will throw an error. Here are a couple repros:

trove:Add(coroutine.running())
trove:Clean()
-- Error: cannot close running coroutine

trove:Add(coroutine.running())
task.spawn(function()
	trove:Clean()
end)
-- Error: cannot close normal coroutine

A thread that is in the "running" state means that it is the currently-active coroutine. A thread that is in the "normal" state means that it has resumed another coroutine and is awaiting that coroutine to yield back.

Thus, another example of the "normal coroutine" error would be such:

local thread1, thread2

thread1 = coroutine.create(function()
	trove:Clean()
end)

thread2 = coroutine.create(function()
	trove:Add(thread2)
	task.spawn(thread1)
end)

task.spawn(thread2)
-- Error: cannot close normal coroutine

And thus comes the question: How should Trove handle this? Should it just have better error messaging? Ideally, developers should only be placing threads into a Trove that they know will be fine to be closed. Simply checking the thread status on Add won't cut it, because that would assume that Clean would be called from the same thread that Add was called, which may not be the case.

Luau is getting generalized iteration through the __iter metamethod. RbxUtil packages should change any use of iterators to take advantage of this.

See:
https://developer.roblox.com/en-us/resources/release-note/Release-Notes-for-526
https://twitter.com/zeuxcg/status/1525204143815524352

Trove:Extend() will create a new trove and add it to the one it was extended from. Clone will call Clone() on the given instance & add the cloned instance to the trove.

-- EXTEND:
local trove = Trove.new()
local anotherTrove = trove:Extend() -- A new trove which will be added to `trove` (but does not clone over items within the trove)
trove:Destroy() -- Cleans up trove AND anotherTrove

-- CLONE:
local trove = Trove.new()
local p1 = trove:Construct(Instnace.new, "Part")
local p2 = trove:Clone(p1) -- Clones p1 and adds it to the trove

I stop and start timers regularly.
It'd be nice to have a property on the timer to see if it is running.

Currently Net RemoteEvent and RemoteFunction methods parent the created instances to the Net module, that's fine. But I found my self having a bunch of modules with identical function names, which is convenient for prototypes and non-professional dev projects (like the one I'm hired to develop).

-- Server
local remoteEvent = Net:RemoteEvent("PointsChanged", Namespace)


-- Client
Net:Connect("PointsChanged", Namespace, function(points)
	print("Points", points)
end)

if no namespace is provided when creating the remote it will just default to the current behavior, parenting to the Net module.

and when calling Connect/Invoke it would search in the provided namespace, if it's not provided then it'' either just do a shallow search within the module (or make it recursive search? Not sure how good that idea is)

Not exactly sure if this is a "good idea" but I found it rather useful for my current situation. Thanks a lot for the module! COMM was just overkill for my use case so this is very appreciated ❤️

Currently, the PreferredInput module exports a type for input types, i.e InputType. I think that in addition, It should export an InputType enum list, so I can use it effectively e.g, PreferredInput.InputType.Keyboard. Currently, I've to use direct strings (the type-auto complete helps) but it'd be better if instead the type could be removed in favour of a dictionary of input types exposed to the developer.

The docs website could benefit from a favicon. I'm raising this mostly because I dislike the default icon for websites in my bookmarks.

RbxUtil lacks any sort of Tween Util. In making a Tween Util, it'd be reassuring for many developers who rely on the utils provided by RbxUtil.

When using IsKeyDown and AreKeysDown, you cannot trust for the result to be accurate as the methods don't take GPE into account.

Hi Sleitnick, I learned about the Knit framework with your Knit Tutorial video, and I appreciate you writing the framework and sharing this great tutorial! I learned a lot from it.

I have a question. Now that using Trove, how can I cancel the delay event of a promise ?(about respawn the ball）I tried to add a dealy promise to Trove, but I was reminded that there was no cleanup function. I can record this promise into a variable and execute its cancel event when the script is destroyed. I wonder if it can be implemented in combination with Trove or something else

Thanks

https://sleitnick.github.io/RbxUtil/api/TableUtil/#Reduce
Has "TableUtil.Filter" instead of "TableUtil.Reduce" in the example.

HI Sleitnick, I start using the knit framework and watch your very good "Knit Game Tutorial".
In the video the util Component V1 ha an Auto method, but in V2 I don't find it.
I create a Goal Component in this way:

local Goal = Component.new({
  Tag = "Goal"
})

function Goal:Construct()
  self._maid = Maid.new()
  print("Goal created")
  self._maid:GiveTask(function()
    print("Goal destroyed")
  end)
end

function Goal:Stop()
  self._maid:Destroy()
end

return Goal

The Goal component is correctly attached to the Goal instances, the problem is that when I add at runtime a new Goal instance with tag "Goal", the component is not automatically attached.

I discovered that if I create the instance on server the component is attached, on the client no. I think this is the right behaviour.

There's a problem with the unit test CI process. For now, unit tests should be run locally before merging any changes. This issue seems to be somehow linked to the run-in-roblox tool. Still need to investigate.

TableUtil's typings are not good. These need improvements.

Whenever FadeOutTime is set to 0 the last shake frame is always returning infinite or 'nan' for the position

https://gyazo.com/d0325e6c40cef831aeb39957bc29ff14

I've discovered some weird behavior with components that I believe is a bug.

Let's say we have a component called "thing".
The construct method of the component includes a task.wait(1) (or some other synchronous function).
If we clone a part with that tag from replicated storage into workspace the construct method of "thing" will run twice.

I've uploaded an example here:
https://github.com/Vilbat/ComponentBug

Edit: The construct method also runs twice if the ShouldConstruct() method yields.

With the addition of coroutine.close, it would be nice if Troves could have threads added to them. When the trove is cleaned up, coroutine.close will be called against the given thread.

local co = coroutine.create(function()
    -- ...
end)
trove:Add(co)
trove:Clean() -- Ends up calling coroutine.close(co)

As far as I'm aware, and please correct me if I'm wrong, but the promise fromEvent created by WaitForInstance if the component class does not currently exist on the object will exist forever if the component class will never actually exist on the object.

A propsal for this could be to add an optional timeout (though the use of Promise:timeout(), which would add safety to the component as the event will resolve itself if the instance doesn't exist after a certain timeframe.

Another propsal could just be to issue a warning, much like the standard Roblox WaitForChild, that would let the developer know that there is a possible infinite wait on the obejct, so that the developer is at least warned that the class does not appear in a timely manor.

Input recently got a new update where it changes how you should access it's modules. After installing the latest version of Input (2.0.0), I cannot access it's modules like the way it is stated in the documentation to do so, e.g local PreferredInput = require(packages.Input.PreferredInput) errors.

This is because of how Wally structures installed packages. Since in the wally packages folder where all my installed packages are, the source code of the Input package module is as follows:

return require(script.Parent._Index["[email protected]"]["input"])

And since the Input module it self returns a nil value, I can't access the modules and I'm forced to use an older version of Input i.e 1.3.3..

Right now, if you want to observe the preferred input, you have to write two lines: one to connect to the change event, and one to fire immediately. It would be nice if there was an Observe method that would do both.

local Input = require(somewhere.Packages.Input)
local PreferredInput = Input.PreferredInput

local connection = PreferredInput.Observe(function(preferred) ... end)

It would be useful to have Connected as a member of signal connections.

Right now it's a private member, _connected.

One thing to note is that it's not just renaming it, but also you would need to change :DisconnectAll to this:

function Signal:DisconnectAll()
        local item = self._handlerListHead
        while item do
            item.Connected = false

            item = item._next
        end
	self._handlerListHead = false
end

To make sure it's consistent with RBXScriptSignal behaviour.

I would open a PR but there's already for one Signal and I'm scared of git collisions that I don't know how to mess with... so...
It's easy enough for you to just change all occurences of _connected to Connected and replace :DisconnectAll with this.

Over the past month I've noticed that after converting old code to use Trove instead of Janitor there were certain scenarios where not all objects in a trove were properly cleaned. It always seemed to involve a promise and I just assumed I was doing something wrong.

However, after a bit of digging tonight, I discovered that Trove occasionally fails to cleanup an object once it cleans a promise added through Trove:AddPromise(). Apparently when a promise is cleaned up, it removes itself from the Trove._objects array, shifting all the proceeding objects, causing the in pairs loop inside Trove:Clean() to skip at least one object if there is one.

It's really easy to reproduce this issue:

local trove = Trove.new()

trove:AddPromise(Promise.delay(5)):finallyCall(print, "Promise cleaned!")
trove:Add(function() print("Fn 1 cleaned!") end)
trove:Add(function() print("Fn 2 cleaned!") end)
trove:Clean()

--> Promise cleaned!
--> Fn 1 cleaned!

TableUtil's documentation shows an example of TableUtil.map() taking in a predicate of form (key, value) -> nil. However, TableUtil'
s code, and documentation states that the predicate is (value, key, tab) -> nil.

The following code from the documentation is incorrect:

local t = {A = 10, B = 20, C = 30}
local t2 = TableUtil.Map(t, function(key, value)
	return value * 2
end)
print(t2) --> {A = 20, B = 40, C = 60}

The code should read:

local t = {A = 10, B = 20, C = 30}
local t2 = TableUtil.Map(t, function(value)
	return value * 2
end)
print(t2) --> {A = 20, B = 40, C = 60

RbxUtil lacks any sort of Zone Util. In making a Zone Util, it'd be reassuring for many developers who rely on the utils provided by RbxUtil. Perhaps if a player is detected in a zone, it'll run a provided callback like PreferredInput, or the user could connect to a signal. It'd also be nice to have Trove and even Component support in some form. An example of this util being used is different zones giving the player different lighting ambiance, so if a Zone is named blue, then it gives a blue tint to the players screen. A proposed name for this util is Region.

Great module! I've been using it for a while, but I'd like see TableUtil.Values(), why not?, if TableUtil.Keys() exists then I guess TableUtil.Values() makes sense

It is currently difficult to fire a RemoteSignal for a specific set of players. FireFilter can work for this, but gets clunky in contexts where the players are already grouped in some sort of table set. Adding FireFor could allow developers to pass a table of players to be fired upon.

Signature:

Signal:FireFor(players: {Player}, ...args: any)

Example:

local players = {someListOfPlayers}
signal:FireFor(players, "Hello there!")

Truncate currently uses table.move into a freshly created table:

local function Truncate(tbl: Table, len: number): Table
	return table.move(tbl, 1, len, 1, table.create(len))
end

When len is greater than or equal to the length of the table, this operation redundantly copies the data; more importantly, it does an out-of-range move (with len > #tbl). We're looking into possibly limiting table.move indices to be in range of 1..#table -- while we haven't finished analyzing the production data for the impact of this change, and aren't sure if we actually want to make this change, a large outlier responsible for ~90% of out of range moves is the use of table-util in a top Roblox game, so it would be great to see if this can be changed in table-util.

Right now there's a minor memory leak with the Component module. When an instance is untagged, it will disconnect the ancestryChangeHandle connection and remove it from watchingInstances, but not from the component class' trove. To fix this, InstanceUntagged should be something along these lines:

local function InstanceUntagged(instance: Instance)
	local watchHandle = watchingInstances[instance]
	watchingInstances[instance] = nil
	
	self[KEY_TROVE]:Remove(watchHandle)
	
	TryDeconstructComponent(instance)
end

You can kill two birds with one stone by using Trove:Remove() to disconnect the connection and to remove its reference from the component class' trove.

On March 7th, Roblox released Destroy() replication, and with that came the long awaited .Destroying event of which is a better alternative to .AncestryChanged as .AncestryChanged fires every time the instances ancestry changes and it's often a shot in the dark, whereas .Destroying ensures the instance is deleted.

Janitor (https://github.com/howmanysmall/Janitor) has already made the switch to .Destroying
https://devforum.roblox.com/t/destroy-can-now-replicate-to-clients/1694890

Component Extensions can only hook into lifecycle events to a component.
While this is nice for creating a component janitor and destroying it when you no longer need the component, it can also restrict what extensions could be. I'm proposing that extensions should be able to hook more deeply into the process. Being able to reject or otherwise prevent component creation would allow for RequiredComponents (from the old V1 module), something which is quite a task with only lifecycle hooks, and more creative ideas.

Currently attempting to index Destroy and Disconnect from the typeof string variable instead of the object parameter

Not sure if this is intentional or if there is a different way of doing this. I want to set state.objects to an empty table, but it does not clear the table.
After it prints Set Empty it continues to print a non empty table.
Code:

local ServerStorage = game:GetService("ServerStorage")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local Silo = require(ReplicatedStorage.Packages.Silo)

local initialState = {
	objects = {},
}

local silo = Silo.new(initialState, {
	Set = function(state, action)
		state.objects = action.objects
	end,
})

silo:Watch(function(state)
	return state.objects
end, function(objects)
	print(objects)
end)

print("populating")
for i = 1, 5 do
	silo:Dispatch(silo.Actions.Set({
		objects = {[(tostring(i))] = true}
	}))
	task.wait(0.1)
end

task.wait(1)

print("Set Empty")
silo:Dispatch(silo.Actions.Set({
	objects = {}
}))

Add a RemoteProperty to Comm, for both the server and client.

Possible API:

Server:

• RemoteProperty.new(defaultValue: any)
• rp:SetAll(value: any)
• rp:Get(player: Player?): any
• rp:Set(player: Player, value: any)
• rp:Clear(player: Player)
• rp:ClearAll()

Client:

• ClientRemoteProperty.new()
• rp:Get(): any
• rp.Changed: Signal<any>

Components should have a GetAll() method to get all components for a given component class.

local MyComponent = Component.new({Tag = "MyComponent"})

...

local componentInstances = MyComponent:GetAll()

Currently the Concur documentation has this:

game:BindToClose(function()
    local all = {}
    for _,player in ipairs(Players:GetPlayers()) do
        local save = Concur.spawn(function()
            DoSomethingToSaveData(player)
        end)
    end
    local allConcur = Concur.all(all)
    allConcur:Await()
end)

The all table is never populated, and as such the allConcur:Await() does nothing. A table.insert (or equivalent) should be added.

It seems like it is possible for the Constructing middleware function to fire twice. Needs to be investigated.

Documentation of the Start method says:

At this point in time, it is safe to grab other components also bound to the same instance.

And it works perfectly when we use multiple components bound to the same Instance. I like this feature, it looks like Knit's Services/Controllers, but with a focus on game entities. All lifecycles are synchronized.

But it is not true if some components yelds the Construct method (for receiving some data for example):

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local CollectionService = game:GetService("CollectionService")
local Component = require(ReplicatedStorage.Packages.Component)


local Component1 = Component.new({ Tag = "SomeTag" })
local Component2 = Component.new({ Tag = "SomeTag" })
local Component3 = Component.new({ Tag = "SomeTag" })
local Component4 = Component.new({ Tag = "SomeTag" })
local Component5 = Component.new({ Tag = "SomeTag" })

function Component1:Construct()
	wait(0.1)
	print("*** Component1 constructed")
end
function Component1:Start()
	print("*** Component1 started")
	print("Component2:", self:GetComponent(Component2))
	print("Component3:", self:GetComponent(Component3))
	print("Component4:", self:GetComponent(Component4))
	print("Component5:", self:GetComponent(Component5))
end

function Component2:Construct()
	print("*** Component2 constructed")
end
function Component2:Start()
	print("*** Component2 started")
	print("Component1:", self:GetComponent(Component1))
	print("Component3:", self:GetComponent(Component3))
	print("Component4:", self:GetComponent(Component4))
	print("Component5:", self:GetComponent(Component5))
end

function Component3:Construct()
	print("*** Component3 constructed")
end
function Component3:Start()
	print("*** Component3 started")
	print("Component1:", self:GetComponent(Component1))
	print("Component2:", self:GetComponent(Component2))
	print("Component4:", self:GetComponent(Component4))
	print("Component5:", self:GetComponent(Component5))
end

function Component4:Construct()
	print("*** Component4 constructed")
end
function Component4:Start()
	print("*** Component4 started")
	print("Component1:", self:GetComponent(Component1))
	print("Component2:", self:GetComponent(Component2))
	print("Component3:", self:GetComponent(Component3))
	print("Component5:", self:GetComponent(Component5))
end

function Component5:Construct()
	print("*** Component5 constructed")
end
function Component5:Start()
	print("*** Component5 started")
	print("Component1:", self:GetComponent(Component1))
	print("Component2:", self:GetComponent(Component2))
	print("Component3:", self:GetComponent(Component3))
	print("Component4:", self:GetComponent(Component4))
end

CollectionService:AddTag(workspace:GetChildren()[1], "SomeTag")

I believe this was removed when table.freeze was added, but table.freeze only fulfills what __newindex did. It does not error if you index a nil value.

In my opinion, it is fairly useful for debugging, especially if you are changing around the Enum names around quite a bit. I had to spend 20 mins to debug an issue related to this, and it would be nice if the behavior matched that of the Roblox Enums, which error if you try to index for a non-existent Enum.