0

My org is soon officially moving us all to Lightning from Classic and I've hit a bit of a snag. Myself and some others have utilized small scripts and bookmarklets to help automate certain quick tasks or for pulling data from the UI to paste elsewhere.

While messy, we have had great success reading values straight from the DOM while also utilizing a couple of the sfdc* stuff we found while poking through the console in Classic.

Lightning, of course, is an entirely different beast and after discovering we're up against Lightning Locker, I don't think we'll be able to take the same approach as we begin converting a couple of these scripts over.

It does appear we have access to a few things like $A.getComponent, but as an outsider looking in, I'm a bit puzzled as to how to tackle this. From what I can see:

  • I can get a reference to components by the ID listed in the attributes on some elements in the DOM (for example 220:0).
    • These IDs appear to change between page reloads, so I can't rely on that.
    • Even with a component reference, the fields and values I'm wanting are deep within and I don't see components for these fields on their own, so I'm not sure how to reference them for their value.
      • The Proxy on HTMLCollection of course does not appear to let me grab the child elements to scrape them, anyways, so this feels like a dead-end.

I recognize that this is heavily org-to-org and will depend on how our CRM team has set things up, but are there endpoints I should be going through to access this information easier?

I can query the API directly with SOQL, but I'd like to avoid having to do any additional requests - especially with the information we're wanting to quickly scrape visible on screen.

I suspect part of the barrier to my understanding is that I'm an outsider looking in where most of the API docs don't appear to be directly relatable as I'm not working with the component source directly and am running outside of the render and other callback things I keep reading about that provide access to more of this stuff. It appears that I am mostly limited to calls made through $A.

Improve this question

1 Answer 1

Reset to default
1

As you've surmised, the DOM is really locked down; it's a security feature. This does hinder your own ability to use Bookmarklets, but that's actually not all bad. You could write a small component that has design attributes to show/copy relevant data, drop it into a Lightning Record Page, and done. Once built, it can easily handle any type of data, without any direct API calls or Apex. You could also build a Utility component that uses the Lightning Console, and it's available for all pages with ease. So, unfortunately, you'll need to invest some time, but it's really not as bad as you think it might be; the "API" for this will never change, so you don't have to worry as much about maintenance.

Improve this answer
2
  • Thank you very much for the details! To confirm, do both of these scenarios require access to the dev side of things that only our CRM team would have or can I create a component and side-load it using some call under $A after the page has loaded?
    – Freesnöw
    Commented Aug 19, 2020 at 18:40
  • 1
    @Freesnöw You'll need your devs to create and deploy the components.
    – sfdcfox ♦
    Commented Aug 19, 2020 at 18:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .