From 99a9837cf923c1a8658785ebf2de4a8eb3cc1505 Mon Sep 17 00:00:00 2001 From: thepaperpilot Date: Tue, 18 Apr 2023 20:25:51 -0500 Subject: [PATCH] Fix typo - thanks incremental_gamer --- docs/guide/advanced-concepts/creating-features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guide/advanced-concepts/creating-features.md b/docs/guide/advanced-concepts/creating-features.md index 4375b921..5f652941 100644 --- a/docs/guide/advanced-concepts/creating-features.md +++ b/docs/guide/advanced-concepts/creating-features.md @@ -6,7 +6,7 @@ Profectus is designed to encourage the developer to eventually start designing t Every feature has a couple of types. They have the feature themselves, a generic version for convenience, and any constructor typically has an options type and a type that gets "added" to it to create the feature itself. These typically involve replacing some types to denote how various properties change from, for example, `Computable` to `ProcessedComputable`. You should be able to use any of the existing features as a reference for how these types look and work. -Most significantly, the base type should typically always have a `type` property pointing to a symbol unique to this feature, so they can be easily differentiated at runtime. If it's a feature that should be renderable, then it'll also need `[Component]` and `[GatherProps]` properties, which describe the vue component to use and how to get the props for it from this feature, as well as a unique ID for the feature's [node](./nodes). You cna use the [getUniqueID](/api/modules/features/feature#getuniqueid) utility to help. +Most significantly, the base type should typically always have a `type` property pointing to a symbol unique to this feature, so they can be easily differentiated at runtime. If it's a feature that should be renderable, then it'll also need `[Component]` and `[GatherProps]` properties, which describe the vue component to use and how to get the props for it from this feature, as well as a unique ID for the feature's [node](./nodes). You can use the [getUniqueID](/api/modules/features/feature#getuniqueid) utility to help. The constructor itself should do several things. They should take their options within a function, so that they're not resolved when the object is constructed. It should return a lazy proxy of the feature, which allows features to reference each other and only resolve themselves once every feature is defined. The constructor should create any persistent refs it may require outside of the lazy proxy - it won't have access to the options at this point, so it should make any it _potentially_ may require. Any that turn out not being needed can be [deleted](/api/modules/game/persistence#deletepersistent). Inside the lazy proxy the constructor should create the options object, assign onto it every property from the base type, call [processComputable](/api/modules/util/computed#processcomputable) on every computable type, and [setDefault](/api/modules/features/feature#setdefault) on any property with a default value. Then you should be able to simply return the options object, likely with a type cast, and the constructor will be complete.