Crate bevy_impulse

Bevy impulse is an extension to the Bevy game engine that allows you to transform bevy systems into services and workflows that can be used for reactive service-oriented programming.

Services

One primitive element of reactive programming is a service. In bevy impulse, a Service is a bevy system that is associated with an entity and can be created using Commands::spawn_service or App::add_service.

When you spawn a service you will immediately receive a Service object which references the newly spawned service. If you do not want to hang onto the Service object, you can find previously spawned services later using the ServiceDiscovery system parameter.

Sometimes Service is not quite the right fit for your use case, so bevy impulse offers a generalization of services callled Provider which has some more options for defining a reactive element.

Workflows

For complex async workflows, a single bevy system may not be sufficient. You can instead build workflows using .spawn_workflow on Commands or World. A workflow lets you create a graph of nodes where each node is a service (or more generally a provider) with an input, an output, and possibly streams.

There are various operations that can be performed between nodes, such as forking and joining. These operations are built using Chain.

When you spawn your workflow, you will receive a Service object that lets you use the workflow as if it’s an ordinary service.

Impulses

Services and workflows are reusable building blocks for creating a reactive application. In order to actually run them, call Commands::request which will provide you with an Impulse. An impulse is a one-time-use reaction to a request which you can chain to subsequent reactions using Impulse::then. Any impulse chain that you create will only run exactly once.

Once you’ve finished building your chain, use Impulse::detach to let it run freely, or use Impulse::take to get a Recipient of the final result.

Re-exports

pub use buffer::*;

pub use builder::*;

pub use callback::*;

pub use cancel::*;

pub use chain::*;

pub use channel::*;

pub use disposal::*;

pub use errors::*;

pub use flush::*;

pub use gate::*;

pub use impulse::*;

pub use input::*;

pub use map::*;

pub use map_once::*;

pub use node::*;

pub use operation::*;

pub use promise::*;

pub use provider::*;

pub use request::*;

pub use service::*;

pub use stream::*;

pub use workflow::*;

pub use trim::*;

Modules

buffer

builder

callback

cancel

chain

channel

disposal

errors

flush

gate

impulse

input

map

map_once

node

operation

prelude

promise

provider

request

service

stream

testing

trim

workflow

Structs

AsyncCallback

Use AsyncCallback to indicate that your system or function is meant to define an async Callback. An async callback is not associated with any entity, and it must return a Future<Output=Response> that will be polled by the async task pool.

AsyncMap

Use AsyncMap to indicate that your function is an async map. A Map is not associated with any entity, and it cannot be a Bevy System. These restrictions allow them to be processed more efficiently.

AsyncService

Use AsyncService to indicate that your system is an async Service. Being async means it must return a Future<Output=Response> which will be processed by a task pool.

BlockingCallback

Use BlockingCallback to indicate that your system is meant to define a blocking Callback. Callbacks are different from services because they are not associated with any entity.

BlockingMap

Use `BlockingMap`` to indicate that your function is a blocking map. A map is not associated with any entity, and it cannot be a Bevy System. These restrictions allow them to be processed more efficiently.

BlockingService

Use BlockingService to indicate that your system is a blocking Service.

ContinuousService

Use ContinuousService to indicate that your system is a Service that runs incrementally inside of a schedule with each update of the Bevy ECS.

ImpulsePlugin

This plugin simply adds flush_impulses() to the Update schedule of your applicatation. For more fine-grained control you can call flush_impulses yourself and configure its relationship to other systems as you see fit.

Traits

Sendish

This trait is used as a trait bound that is equivalent to Send except when the single_threaded_async feature is active, in which case it is no longer a bound at all because the single threaded async executor does not require tasks to be Send.

Type Aliases

AsyncCallbackInput

Use this to reduce bracket noise when you need In<AsyncCallback<R, S>>.

AsyncServiceInput

Use this to reduce backet noise when you need In<AsyncService<R, S>>.

BlockingCallbackInput

Use this to reduce bracket noise when you need In<BlockingCallback<R, S>>.

BlockingServiceInput

Use this to reduce bracket noise when you need In<BlockingService<R>>.

ContinuousServiceInput

Use this to reduce the bracket noise when you need In<ContinuousService>.