Parse sObjects in the landing page and return them in an array #51
Conversation
|
You're going to need to rebase against |
|
@khawkins On resolving the conflict now. I was talking with @dbreese but after resolving we will need a refinement in how we render the table as we'll now have both what sObjects that we are generating for and what sObjects' QAs already exist. So this may not come clear after my merge conflict, just a heads up. |
Yeah we need to resolve, for sure. Looking at both implementations, I don't think the results of your functionality (finding the sObjects represented in the landing page) should be going back to the UI. That's functionality that the LWC generation code needs to invoke, to understand what it needs to generate. To me, that's what should be (and currently is) going back to the UI. I think the sObject interrogation in the landing page should just be represented as functionality internal to the process. Cc: @dbreese |
|
@dbreese @khawkins I am now working on exactly that, making interrogation as a part or internal to finding which sobject's QA to generate(view/edit/create). The way it is set up now |
src/utils/uemParser.ts
Outdated
| return results; | ||
| } | ||
|
|
||
| static findObjectsWithValues( |
There was a problem hiding this comment.
Sorry, I'm still not convinced on "searching" the JSON. The JSON in question in this case is a well-known data structure. We should be querying it, not searching it. For all of its unwieldiness, it's still deterministic that objectApiName keys can be found at view.regions.components.components[_x_].regions.components.components[_y_].properties.objectApiName (or something along those lines). I haven't looked across all of the templates to see whether or not there may be a similar path to other ones—but if there is, it will be just as deterministic.
I feel like we should be deliberate about access these data properties. To me, searching for them is just opening a door to false positives, with no real upside. We should query the data structure we know.
There was a problem hiding this comment.
I wasn't sure if it will always be in that location. I suggested to @sfdctaka that as long as we find an mcf/list or mcf/timedList, then from there .properties.objectApiName should be populated. I thought that with the UEM file, it can be arbitrarily deep and nested in other components such as an mcf/card or something else perhaps.
There was a problem hiding this comment.
I support continuing to have some measure of a UEM "fronting" class for these data structures, because they are so unwieldy, and accessing properties therein in a more friendly encapsulated manner could be useful down the road.
There was a problem hiding this comment.
I thought that with the UEM file, it can be arbitrarily deep and nested in other components such as an
mcf/cardor something else perhaps.
It'd be good to understand if that's the case, and then if so what the constraints are on that definition, and how we'd respond to them.
My point is more that we should strive to leverage our understanding of this data structure that we're supporting. To do a "find" is kind of punting on that understanding, and to me exposes a gap that we need to close.
There was a problem hiding this comment.
I wrote a xpath-ish query function to replace the recursive deep search. @khawkins please check it out.
|
@khawkins Made the search to simpler, to look for all |
|
I think the last commit could be the final dagger, @khawkins . |
Pretty close! 😆 I think all that's left is to just remove those now-redundant tests in |
No description provided.