Here, we need to pass the symbol or the string name because this is the place of prop where it is checked if the symbol or string belongs to the object. This is done using the method given below.
One important aspect to note here is that the method hasOwnProperty() generally ignores inherited properties. This means that method shall return its true if the object is found to have a non-inherited property and the name is specified by propname. If it returns false, then it means that the object does not have any property with a specified name, or it has inherited the property from the object of the proptype.
Another added advantage of using the hasOwnProperty() method is that it can initialize an object by following up with the concept of passing a string as the default argument. It shall respond quickly with true if the value is found to be available to the object. Else, it will return false if not found. It can be demonstrated using the code snippet given below.
In the code snippet given above, the variable creates a new object, Car. It can now be stated that the Car is initiated having its properties and name defined under the constructor. Although the colour might not be mentioned within the object when initiated, it will always be available on the prototypical hierarchy. Therefore, the hasOwnProperty() will return true always for the name, but for colour, it will return false.
When it comes to performance, hasOwnProperty() works smoothly while making its way through the object with loops. By now, we can say that if the properties specifically belong to the object. They don't have any correlation with the prototype. The demonstration of this can be shown using the code snippet given below.
While using the hasOwnProperty() method, it may turn useless because the rendering of the object happens when defining a property named hasOwnProperty. To support this, try to understand the code snippet given below.
In the above code snippet, it is evident that harrypotter already have hasOwnProperty. Thus, it will never make a call to the object.prototype.hasOwnProperty. It is assumed that this might encounter cases where it may allow to make a call, but it may eventually fail. So, it is always recommended to be aware of the possibility of calls. The below code snippet shows its workaround.
In the above code snippet, it is clear that harrypotter defines its own hasOwnProperty. It will never make calls to the Object.prototype.hasOwnProperty because there is a possibility that it may return false if it encounters some cases where the value is false and it becomes difficult to make things work around the corner. To support this statement, see the code snippet given below.
Similar to the hasOwnProperty, there is another method called "in" method. It is also used to check if the key is present for the object or not. However, it is important to note that is the key difference between hasOwnProperty and in method lies in the fact that the in method will not follow the order of distinguishing between the properties that get inherited and the that inherited properties are specially created for the object. This can be shown using the code snippet given below.
In the above code snippet, it is evident that the 'in' method follows the constructor property of Object.prototype from where all the objects get inherited.
To add a few points, there is a disadvantage for both the methods. Both the methods can easily give us the information about a property that has already been declared but they can't tell us about the property containing a real value.
Consider the following code snippet that shows how both the methods carry this workaround.