entity->getValueMap() is not a direct replacement for toArray()

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • bandtank
    Active Community Member
    • Mar 2017
    • 385

    entity->getValueMap() is not a direct replacement for toArray()

    Can someone explain why toArray has been replaced by getValueMap:
    Code:
        public function getValueMap(): stdClass
        {
            $array = $this->toArray();
    
            return (object) $array;
        }
    This is basically the same thing, except the object is harder to use than the array. I am having to modify hundreds of lines of code in my extensions and customizations to deal with this, and I am doing the following to make it work:
    Code:
    $arr = (array)$entity->getValueMap();
    I don't see how this is an improvement, and it is causing a ton of work for me. I know the getValueMap function has been around for a long time, but I never switched because it runs much more slowly than simply using toArray.
  • yuri
    Member
    • Mar 2014
    • 8586

    #2
    It has been deprecated for more than 5 years. The method was set to be removed in v9.0. IDEs strike through deprecated methods warning developers not to use it. It's also possible to use search for all deprecation usages to fix code.

    I never use toArray nor getValueMap in code. I encourage not to use associative arrays as value containers in business logic and prefer type-safe code.

    The only use of getValueMap is in the very end of API actions to send entity data to output or before storing/serializing entity data. As the array type is a woe in PHP (it's both a map and a list), the object map is preferable, because it's explicitly a map. An empty map will be encoded as a JSON object not as an empty array what is the source of bugs which usually are caught late on production.
    Last edited by yuri; Yesterday, 10:03 PM.
    If you find EspoCRM good, we would greatly appreciate if you could give the project a star on GitHub. We believe our work truly deserves more recognition. Thanks.

    Comment

    • bandtank
      Active Community Member
      • Mar 2017
      • 385

      #3
      I disagree with most of what you said - especially that array types are not acceptable - but it doesn't really matter since I have no control over this. I'll just continue to cast the objects to arrays because that is a perfectly sensible solution. This change was not beneficial to anyone, and it doesn't make the software better, but I digress.

      Comment

      • yuri
        Member
        • Mar 2014
        • 8586

        #4
        It may not make it better for a particular developer. But there's another perspective a developer may not see. They may see only own benefits but not see benefits of the platform developer. Dealing with less future bugs in 3rd party code is for good.
        If you find EspoCRM good, we would greatly appreciate if you could give the project a star on GitHub. We believe our work truly deserves more recognition. Thanks.

        Comment

        • yuri
          Member
          • Mar 2014
          • 8586

          #5
          Code to demonstrate how the system used to break with toArray usage:

          PHP Code:
          $entity = $this->service->fetchPatriallyLoadedEntity();
          $this->recordService->applyFieldLevelAccess($entity);
          
          return Json::encode($entity->toArray()); // An empty entity becomes [] instead of {} and the frontend fully breaks. 
          

          Regarding array usage in business code.

          This is 20 year old way to go:
          PHP Code:
          $array = $entity->toArray();
          
          $array['date']; // date-string 
          

          This is a normal way to go:
          PHP Code:
          $date = $entity->getDate(); // Date object. 
          
          If you find EspoCRM good, we would greatly appreciate if you could give the project a star on GitHub. We believe our work truly deserves more recognition. Thanks.

          Comment

          Working...