Actions - Improved & Open Source (now in beta)

We listened to your feedback and we’re excited to announce the next generation of Pipedream actions is live in beta!

Improvements include:

  • Open Source, Hosted on Github - Similar to sources, verified actions are now hosted in Pipedream’s Github repository. Want to contribute a new or updated action? Just create a PR.

  • Simplified Configuration - Use drop down menus instead of searching for and entering IDs — for example, when selecting a Google Sheet, an Airtable base or a Slack channel.

  • Local Development - Develop actions locally, publish via CLI and maintain the code in your own Github repo.

  • My Actions - Your own, private actions are now easier to find. Just select My Actions in the workflow step selector.

  • Click to Update - Say goodbye to deleting actions in workflows and re-adding and re-configuring them just to update to the latest version!

Ready to build your first component action? Start with our quickstart guide. If you created any legacy actions, learn how to migrate to components.

As always, let us know if you have any questions or feedback!

3 Likes

Looks great! Thanks a lot for this. I have been looking at the docs today to hopefully migrate my custom actions.

There are a few inconsistencies in the docs though:

  • The “Actions Quickstart” guide uses “pd publish” to push the new action and all updates to pipedream but “publish” is not documented anywhere, not on the CLI reference docs, not on the component docs, only in the CLI “–help” it shows “publish” BUT in the CLI help it does not mention “deploy” while that’s what’s used in the “Sources Quickstart” and the rest of the docs. That’s quite confusing.
  • The “Actions Quickstart” uses the component option “type” set to “action” so I would assume I would have to set that to “source” when developing a source but in the “Source Quickstart” it never even mentions that option and in the component reference docs, this option is not even listed at all.
  • The “Sources Quickstart” mentions the “pd dev” which is also not documented anywhere exception with a mention in the CLIs “–help” output. Is there any way to test Actions without creating a Workflow and constantly re-publish, update in UI, run?
  • The “Sources Quickstart” only discussed “pd dev” but does not mention if it also uses “publish” for deployment like actions
  • What’s the difference between “update” and “publish”/“deploy”? The “Actions Quickstart” tells me to just “publish” with an incremented version or it would error, so would “update” allow me to modify an existing version without the need fro the user to then manuallyu upgrade the action?
  • The Lifecycle diagram does not show up in the docs
  • The “Actions Quickstart” simply returns a value but everywhere else it’s documented that you should use “this.$emit()”. This has been the case before as well but then it was at least documented that the emit should be used when you want to generate mutliple events from the same action, otherwise you could just return, nothing like this is mentioned now.
  • The CLI docs say that it’s only for sources but the Quickstart also uses it for actions
  • The used “key” in the “Actions Quickstart” does not follow your recommended best practices mentioned in the component ref docs
  • Do I see this correct, that props don’t have a “placeholder”/“example” anymore?
  • The Interface Props overview table doesn’t list DB but it is documented on the page
  • I don’t understand “propDefinitions”, “app” objects and “app” props. They all seem to mix the “app” naming to mean different things I think. “app” props are for managed auth I think? But the “app” objects for the “propDefinitions” are something else? Especially as you define the following in your component: pipedream/new-item-in-feed.js at 519b63d240aee695688699853d4c75f7f4dd59e1 · PipedreamHQ/pipedream · GitHub but you include the exact same thing again here: pipedream/new-item-in-feed.js at 519b63d240aee695688699853d4c75f7f4dd59e1 · PipedreamHQ/pipedream · GitHub

I’m sorry to say but I am more confused than anything else after reading the docs… There are probably a lot more things like this that I just didn’t see yet. Please go through the docs and update them to be more consistent and clear.

It would also be amazing if the custom actions would at least be listed in the UI just the same way custom sources are. Currently I can’t see my custom action anywhere but in the workflow editor and can’t delete/unpublish it from the UI.

1 Like

Hi @chrigi - welcome to the community! Component actions are currently in beta and we are continuing to iterate so your feedback is valuable — thanks for sharing! If you’re open to it, I’d love to connect over Zoom to discuss more and learn about your use cases. Feel free to schedule time on my calendar via Calendly. I’ll also try to address your questions as best I can below.

First, sorry for the gaps you noted in the docs — we’ll get those loaded up on our backlog to address. If you have an opinion on where specific clarifications would have helped and you want to contribute, you can submit a PR to our docs on Github. If not, we’ll address them!

Following are responses to your specific questions:

The “Actions Quickstart” uses the component option “type” set to “action” so I would assume I would have to set that to “source” when developing a source but in the “Source Quickstart” it never even mentions that option and in the component reference docs, this option is not even listed at all.

The type field was introduced for the actions beta (it is currently not required for sources). We expect that this will be added to sources once we further validate the changes made for the actions beta.

Is there any way to test Actions without creating a Workflow and constantly re-publish, update in UI, run?

Not currently. However, this is on our radar as we iterate on the beta release.

The “Sources Quickstart” only discussed “pd dev” but does not mention if it also uses “publish” for deployment like actions

We haven’t announced source publishing yet, but we’re working on it — stay tuned!

What’s the difference between “update” and “publish”/“deploy”?

When you deploy a component to Pipedream you create a running, configured instance. For example, when you deploy the RSS source, you configure it with the feed URL and it creates a resource that runs independently on Pipedream and emits new items as events (which can be used to trigger workflows). The update command allows you to modify a specific deployed instance (e.g., you can update the code or configuration).

When you publish a component, you essentially create an un-configured template that can be instantiated. For example, published actions can be added to a workflow where they can be configured, and the workflow can be deployed, but the published actions themselves don’t run independently.

The used “key” in the “Actions Quickstart” does not follow your recommended best practices mentioned in the component ref docs

When you publish a component to your own account, you can name the key anything you want (you should just make sure it’s unique across all of your components). The specific key structure that is defined in the docs only applies to components that are submitted to the Pipedream registry on Github.

Do I see this correct, that props don’t have a “placeholder”/“example” anymore?

Correct. Component props don’t currently support “placeholder” text, but that is planned.

The Interface Props overview table doesn’t list DB but it is documented on the page

db is a service prop — you can learn more here: Component API Reference. Let me know if I misinterpreted your feedback.

I don’t understand “propDefinitions”, “app” objects and “app” props. They all seem to mix the “app” naming to mean different things I think. “app” props are for managed auth I think? But the “app” objects for the “propDefinitions” are something else? Especially as you define the following in your component: pipedream/new-item-in-feed.js at 519b63d240aee695688699853d4c75f7f4dd59e1 · PipedreamHQ/pipedream · GitHub but you include the exact same thing again here: pipedream/new-item-in-feed.js at 519b63d240aee695688699853d4c75f7f4dd59e1 · PipedreamHQ/pipedream · GitHub 1

We are still working on improving the experience when working with app libraries in components. The issues you noted with the RSS source are definitely a bug. I’ll make sure that’s logged for resolution.

It would also be amazing if the custom actions would at least be listed in the UI just the same way custom sources are. Currently I can’t see my custom action anywhere but in the workflow editor and can’t delete/unpublish it from the UI.

We plan to introduce a UI to manage your published components (so you view, delete, share, etc). I created a Github issue that you can +1 and follow.

I hope that helps answer some of your questions. Feel free to follow up if you have any other questions. And again, it would be great to connect over Zoom if you’re open to it.

Thanks,
Pravin

Thanks a lot for taking the time to answer @pravin :slight_smile:

Regarding the discussion, I scheduled something over Calendly but I am just doing pipedream stuff on the side, for my hobby projects and to automate my life, not professionally, so I don’t want to waste your time if it’s a business lead you are after.

Just two remarks regarding your answers:

db is a service prop — you can learn more here: Component API Reference. Let me know if I misinterpreted your feedback.

I just meant that the table here just doesn’t list it but should: Component API Reference but afterwards I have found that this is probably not the only location where something like this is the case as well as there are other images not visible in different articles on the docs.

We are still working on improving the experience when working with app libraries in components. The issues you noted with the RSS source are definitely a bug. I’ll make sure that’s logged for resolution.

It would be really great to get some details regarding props of type “app”. Going with the code on GitHub it looks to me as if it’s used to share code & data between multiple sources and actions of the same app but the docs are mainly about sharing propDefinitions and enabling auth.

In general I’m looking forward to this new system. Especially being able to create custom sources is exactly what I wanted.

I do hope though that you won’t abandon the in-browser dev einvornment. The text editor itself is a bit painful but the workflow of developing an action in a workflow and testing it inline to ultimatley be able to move it to a re-usable action was really nice. Would love (would have loved) if this was also possible for sources. Currently it’s not perfectly clear to me if you will be moving all re-usable actions & source dev out of the web ui into our own git and tools or if you will be updating/extending the web editors. Maybe some sort of integration with codespaces on github could power a more flexible in-browser dev workflow.

@chrigi - it’s definitely not a waste of time, and I’m not looking for a business lead :slight_smile: My goal is to learn more about your needs to help us build the best product — meeting with our users to get feedback is one of the most valuable ways we can spend our time! So thank you again for your thoughtful feedback, and I look forward to connecting live!

Thanks,
Pravin

I also liked how with old actions I could easily modify the action code to customize it in place for a particular workflow — I don’t see a way to do that in this new style of action.

For instance, right now I have a step where I’m looking up a record based on an id from a previous step, but that previous step doesn’t always include a record. The action is complaining if I don’t include an id and there’s no easy way to go in and adjust the code so it just skips the step if no id is provided. I’ll have to write my own version from scratch.

I’d love it if there was button I could press on the action to convert my action into a generic code-step with the action code already present so I can use it as a starting point!

3 Likes

I hear you. This one is on our backlog.

1 Like

Since the migration guide implies the web editor is going away I would be curious to hear more about what the long term plans for the editor are. The web editor or rather the capabilities it offers are a main reason why I use Pipedream (plus the easy auth).

I mainly use event triggered workflows and none of the IDEs I’ve used allow me to see actual event data before I even write the code. I’ve looked for plugins that might provide this functionality and couldn’t find any. The web editor’s auto-complete function being aware of that data makes it extremely fast to write code as well. It makes integrating with services so easy and massively mitigates bad documentation.

I agree with CelesteBancosHP that being able to modify existing actions while building a workflow is also a huge advantage of the web editor.

I don’t mean to downplay the changes highlighted in the original post. All of them genuinely sound fantastic. I just don’t want to lose all of the critical productivity boosts the web editor provides.

Thanks!

1 Like