evaera / fabric Goto Github PK

1. destroy part on server
2. component on server destroyed
3. component on client destroyed (independently of server, since it uses collectionservice)
4. component on client tries to tell server something, (i'm assuming unsubscribe) but error on server since cannot deserialize already destroyed component on part

Dynamically look for: limitClientSetTransparency

method on component definition:

	validateSubscribeRequest = function(self, player)
		return true
	end

Map of

:exportLayers returns map of layer scope -> layer data. The map does NOT contain layers whose scope is a table.

{
  {
    layerNameString = layerData
  },
  ...
}

:addManyLayers restores this data structure into the component as layers

Very vague for now. Not sure how I want this to work yet.

But basically, there should be an optional extension that makes running some code on every event (like Heartbeat, RenderStepped, etc) or on an interval easy.

There should only be one cycle per component type. Meaning if you have multiple "Door" components, and the component has a Heartbeat event setup, there's only ever one Heartbeat connection, and all Doors update sequentially.

This is good for performance reasons as opposed to creating a new event for each and every component.

This prevents memory leaks + makes it much easier to provide other components

Method 1 (current)

The effects currently track what :get() calls you use inside of them to determine what keys need to be tracked. This works because all effects run when onAdded fires.

Pros:

• Automatic optimization of keys to access
• Can access keys from other components and it works just the same

Cons:

• If the user puts any :get() calls behind different code paths, some of them might not get hooked correctly. This is a potential source of mistakes.
• If there's an error when the effect first runs, it won't be able to track keys that were supposed to be accessed behind the error.

Method 2 (proposed)

An alternative would be to make the user explicitly pass which keys they want to re-run the effect for.

Pros:

• Makes the two above potential mistakes impossible
• onAdded event can be removed, because that's just the same as an event with no keys being watched
• More flexible in that you could re-run the effect when a key that you don't even access changes.

Cons:

• Can't access keys from other components in a natural way
• Optimization is now opt-in

Questions:

• Should we pass the listed keys to the function handler as a convenience, or should we make the user access the keys manually?

If we switch to method 2, how do we access data from other components? Should we invent a special object you pass to the key tracking list in place of a key, that includes the key, ref, and component that you want to access?

Dynamically look for: validateClientSetTransparency

If you return a function from an effect, it is run when:

• The unit gets destroyed
• Before that effect re-runs

Obsoletes #8

Maybe with StringValues, to prevent pop in

after defer

This makes the guarantees about when it is available a bit safer. Right now, it is sometimes available in effects, but other times not.

That's a mouthful. I'm sure I'll remember what I meant by that...

create method which returns an “uncreate” function. This will allow hot reloading to create stuff.

shorthand for self:on("destroy", cb)

• For all event methods
• For all event listeners
• For all effects

Otherwise, the component will get removed when the predictive layer is removed.

Facilitate components communicating with events in a way that's statically configurable. This means that a Studio plugin would be able to be created, which for example allows you to connect a part with a Button component to a part with a Door component. The Button "press" event could be connected to the door's "open" method.

INstead of hte transmitter

If server -> client with nil data, client component gets removed. This means if the server component ever gets created again later, the client component will never come back.

FabricLib.useRoact(fabric, roact)

Mount a roact tree on the ref if the component contains a render function: on component create, we mount if render exists, then call render. on destroy, unmount

This gives time for all components to register before creating them.

Because it's confusing and not useful

Empty table should be the same as passing nil to a layer

local weakSelfContainer = setmetatable({ self = self }, { __mode = "v" }) then use weakSelfContainer.self in the disconnect callback