fix: [Angular] fix logic used for parsing objects provided as input to useObjectWrapper

[lukjab71]

Description

This is propsed fix to issue: 1410

• What changes you made:
  The logic responsible for parsing an input to the method was incorrect. It used ',' comma as object separator. This gave weird results for any other constructs that would use comma, like arrays. Besides, this logic should probably be used only when input actually has spread operator in it.

Regardless from object detection logic, I'm not convinced if logic responsible for concatenation ${spreadOutObjects.join(', ')}, ${otherObjs.join(', ')} was correct. spreadOutObjects collects objects that use spread operator. otherObjs collect the rest of the objects from input. When we concatenate them using the initial logic, I believe we are completely mixing the order of objects, as there is no guarantee that spreadOutObjects in the original input, where at the begining. What if they were spread out somewhere else, in some nested object, of some complicated input? I believe this would either completely malform the object or in best case change the object structure.

Now, about the propsed solution. As I understand, the whole purpose of this method is to get rid of ... spread operator from syntax, as angular won't accept it.

I tried to approach this problem in recursive way(to fix initial way of detecting objects - instead of using comma as object separator, try to figure start bracket and end bracket), but it is tricky, as regex are not good with recursive problems and even when I extracted recursion to separate method, it still was tricky for some complicated examples. And then I switched the approach - in the end, why do we need to detect separate objects? Our goal is to get rid of ... from the string. So we can simply get rid of the ... and then deal with potential consequences:

1. someField: ...someObject -> remove ... and we are done
2. someField: {...someObject} -> remove ... and we are left with {object} result
3. someField: {...{nestedDeeper: true }} -> remove ... and we are left with {{ something: true }} result

I believe those cases will cover every possible variations on different levels of nesting. So after removing ... we just have to cleanup what's left.

I prepared the PR using remarks from CONTRIBUTING.md file, however, I noticed that even without my changes there are tests failing in the core package(?).

[changeset-bot]

🦋 Changeset detected

Latest commit: 9ad3dab

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@builder.io/mitosis	Minor
@builder.io/mitosis-cli	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR