Fivem Props
Adah
@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.
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.