Prop Fivem

6 views
Skip to first unread message

Kathy Douds

unread,
Jul 26, 2024, 2:12:48 AM7/26/24
to gem5-Aladdin users

Previously in creator, if I snapped a piece of track to another for example, then went to the Advanced settings and Position, switched from World to Local, and made adjustment of the X, Y and Z axis values, this would move the second piece of track relative to its position, i.e. snapped to the first.

Now what happens is that going into the advanced position defaults the rotation settings of the second piece of track to X: 0,00 Y: 0,00 and Z: 0,00, and this automatically moves it away from the first piece and spins it around to the default settings above

Ok I haven't been in the Race creator since a while, now I get it. What you could still do is use a prop as a supporting structure, for example a large building block. Get the correct rotation via edit -> cancel, select your supporting prop and place it. then put your props on top of it (with prop stacking) and aling them using the straight lines that you can see on the prop. That way, the props keep exactly the same rotation.

Creates an object (prop) with the specified model at the specified position, offset on the Z axis by the radius of the object's model.This object will initially be owned by the creating script as a mission entity, and the model should be loaded already (e.g. using REQUEST_MODEL).

The goal of this post is to not only help you understand what prop drilling is(some also refer to it as "threading"), but also when it can be a problem andmechanisms you can use to side-step or avoid it.

Prop drilling (also called "threading") refers to the process you have to gothrough to get data to parts of the React Component tree. Let's look at a verysimple example of a stateful component (yes, it's my favorite componentexample):

This is prop drilling. To get the on state and toggle handler to the rightplaces, we have to drill (or thread) props through the Switch component. TheSwitch component itself doesn't actually need those values to function, but wehave to accept and forward those props because its children need them.

Did you ever work in an application that used global variables? What about anAngularJS application that leveraged non-isolate $scope inheritance (or thedreaded $rootScope ?) The reason that the community has largely rejectedthese methodologies is because it inevitably leads to a very confusing datamodel for your application. It becomes difficult for anyone to find where datais initialized, where it's updated, and where it's used. Answering thequestion of "can I modify/delete this code without breaking anything?" isdifficult to answer in that kind of a world. And that's the question you shouldbe optimizing for as you code.

One reason we prefer ESModules over global variables is because it allows us tobe more explicit about where our values are used, making it much easier to trackvalues and eases the process determining what impact your changes will have onthe rest of the application.

Prop drilling at its most basic level is simply explicitly passing valuesthroughout the view of your application. This is great because if you werecoming to the Toggle above and decided you want to refactor the on state tobe an enum, you'd easily be able to track all places it's used by following thecode statically (without having to run it) and make that update. The key here isexplicitness over implicitness.

In our contrived example above, there's absolutely no problem. But as anapplication grows, you may find yourself drilling through many layers ofcomponents. It's not normally a big deal when you write it out initially, butafter that code has been worked in for a few weeks, things start to get unwieldyfor a few use cases:

One of the things that really aggravates problems with prop drilling is breakingout your render method into multiple components unnecessarily. You'll besurprised how simple a big render method can be when you just inline as muchas you can. There's no reason to break things out prematurely. Wait until youreally need to reuse a block before breaking it out. Then you won't need to passprops anyway!

Fun fact, there's nothing technically stopping you from writing your entireapplication as a single React Component. It can manage the state of your wholeapplication and you'd have one giant render method... I am not advocating thisthough... Just something to think about :)

Another thing you can do to mitigate the effects of prop-drilling is avoid usingdefaultProps for anything that's a required prop. Using a defaultProp forsomething that's actually required for the component to function properly isjust hiding important errors and making things fail silently. So only usedefaultProps for things that are not required.

Keep state as close to where it's relevant as possible. If only one section ofyour app needs some state, then manage that in the least common parent of thosecomponents rather than putting it at the highest level of the app. Learn moreabout state management from my blog post:Application State Management.

Use React's Context API for thingsthat are truly necessary deep in the react tree. They don't have to be thingsyou need everywhere in the application (you can render a provider anywhere inthe app). This can really help avoid some issues with prop drilling. It's beennoted that context is kinda taking us back to the days of global variables. Thedifference is that because of the way the API was designed, you can stillstatically find the source of the context as well as any consumers with relativeease.

@candice_211 Hi there, I've made a SAMS re-texture for the stretcher prop and I was wondering if you'd have any issue with me uploading it? I will credit you of course. (I also edited the embedded texture in the ydr)

@A1Draco I love what you've done with this! This is probably a 'big ask' at this point, could you include individual bathroom props (i.e. the stylish toilets, shower units and shower heads, sinks)? The complete bathroom units you provided are great, but a specifically sized space is required to use them properly. Individual pieces would give more creative choices. Lastly, it is great you included buildings if you could also provide versions with the windows and doors cut out, it would be a lot easier to convert them to interiors for those who don't have 3DSMax. Even if you can't (or won't) put in these additions, it's still a wonderful mod and your work is much appreciated!

@A1Draco Finally got a chance to dig into the last batch of props. Looks great. Only thing I wished for was that you cut open the entrances to the apartment interiors. It would be a lot easier to connect elevators or make stairwell entrances. Also cutting open the doorways in the halls where additional apartments would be would have been great too. Still though, lots of stuff to work with!

@neveahfoxx not sure honestly, I know it's got the executive businesses CEO garage's. I haven't looked at this mod in awhile sorry. I will update the mod eventually, just currently working on other projects.

@iammistahwolf Sorry for the very very late response, i've been working on other project's and I haven't checked the website in a bit. I do eventually want to update this mod and add the suggestions you asked for. Thank you for the suggestions and support.

PropTypes was originally exposed as part of the React core module, and iscommonly used with React components.Here is an example of using PropTypes with a React component, which alsodocuments the different validators provided:

First of all, which version of React are you using? You might be seeing this message because a component library has updated to use prop-types package, but your version of React is incompatible with it. See the above section for more details.

When you migrate components to use the standalone prop-types, all validator functions will start throwing an error if you call them directly. This makes sure that nobody relies on them in production code, and it is safe to strip their implementations to optimize the bundle size.

If you absolutely need to trigger the validation manually, call PropTypes.checkPropTypes(). Unlike the validators themselves, this function is safe to call in production, as it will be replaced by an empty function:

Reply all
Reply to author
Forward
0 new messages