Nice blog post

[alexed1]

I referenced it on unofficialsf.com

You may find these extensions interesting: https://unofficialsf.com/flow-test-builder/ https://unofficialsf.com/a-graphical-soql-query-builder-for-flow/

We're always interested in featuring reusable invocable actions and screen components. I'm trying to grow the pool of Apex developers who have the ephiphany you had about invocable actions being exciting because of the potential to grow a huge common library of reusable components.

Feel free to reach out if you do any more Flow Apex exploration. Chris Peterson, the Apex PM here at Salesforce, is also interested in explorations on this particular frontier, and this can lead to opportunities to feature your work, yourself, and your company. (See the flow chapter 2 in this for an example).

[aidan-harding]

Hi Alex,

Thanks for letting me know that you enjoyed it.

I saw you presenting the test builder in the release readiness video. It looks like it's addressing a different thing than what I was driving at, but useful for its use-case. I'll definitely check out the SOQL builder.

If I did want to reach out, what's the best way to contact you? If you don't want to share here, fee free to email me aidan@nebulaconsulting.co.uk.

I've already bugged Chris plenty about the things I want from Apex 😃 Generics, covariant return types, anonymous inner classes, etc.

[adwhite75]

Agreed - really good article @aidan-harding ! I learned a few things myself. Neat use of apex-defined types with Trigger.Old/New. Completely agree with you about Flow being declarative coding. I think admins out there are really going to have to up their skillset to take advantage of Flow and Alex & team have a mountain ahead of them to try and simplify Flow.

As Alex said we'd love your participation in USF components! I personally would love it if you could help figure out how to properly bulkify the ExecuteSOQL action we have on UnofficialSF - its one of my favorite actions but has its limitations when used in an undefined scope.

https://github.com/alexed1/LightningFlowComponents/tree/master/flow_action_components/ExecuteSOQLQuery

We've also been struggling with how to tackle sharing actions/components with respect to test classes. We've been discussing either going managed package route or packaging up some custom objects used for test class validation. We'd love your thoughts there!

[aidan-harding]

Hi Adam,

I have a couple of thoughts on how you could write a bulkified version of ExecuteSOQL. It would probably be a whole different component, though. I think that the key would be not to take a string as input, but to take something more structured so that you don't have to parse it, and you can restrict it to only do bulikifiable things.

On testing, I'd definitely be looking at mocking to test components like this. You can safely distribute mocked pure unit tests. To make sure that the component really does work, you'd still have to run integration tests against a real database when you build the package. But mocking works well for distribution. I had a play around with mocking here: https://github.com/aidan-harding/apex-stub-as-mock; fflib does it with apexmocks (although it takes a ton of LoC to do it); and @bobalicious has a mocking library here https://github.com/bobalicious/amoss

I'm super-busy at the moment, but I'll try to engage with UnofficialSF at some point over the next few weeks.