85 lines
3.3 KiB
Rust
85 lines
3.3 KiB
Rust
//! An event system that's less confusing than Traits + RC;
|
|
//! This should hopefully make it easier to port to other platforms.
|
|
//!
|
|
//! Unfortunately, it is less efficient than the original, but hopefully it's negligible.
|
|
|
|
use crate::{
|
|
innerlude::Listener,
|
|
innerlude::{ElementId, NodeFactory, ScopeId},
|
|
};
|
|
use bumpalo::boxed::Box as BumpBox;
|
|
use std::{
|
|
any::Any,
|
|
cell::{Cell, RefCell},
|
|
fmt::Debug,
|
|
};
|
|
|
|
#[derive(Debug)]
|
|
pub struct UserEvent {
|
|
/// The originator of the event trigger
|
|
pub scope: ScopeId,
|
|
|
|
/// The optional real node associated with the trigger
|
|
pub mounted_dom_id: Option<ElementId>,
|
|
|
|
/// The event type IE "onclick" or "onmouseover"
|
|
///
|
|
/// The name that the renderer will use to mount the listener.
|
|
pub name: &'static str,
|
|
|
|
/// The type of event
|
|
pub event: Box<dyn Any + Send>,
|
|
}
|
|
|
|
/// Priority of Event Triggers.
|
|
///
|
|
/// Internally, Dioxus will abort work that's taking too long if new, more important work arrives. Unlike React, Dioxus
|
|
/// won't be afraid to pause work or flush changes to the RealDOM. This is called "cooperative scheduling". Some Renderers
|
|
/// implement this form of scheduling internally, however Dioxus will perform its own scheduling as well.
|
|
///
|
|
/// The ultimate goal of the scheduler is to manage latency of changes, prioritizing "flashier" changes over "subtler" changes.
|
|
///
|
|
/// React has a 5-tier priority system. However, they break things into "Continuous" and "Discrete" priority. For now,
|
|
/// we keep it simple, and just use a 3-tier priority system.
|
|
///
|
|
/// - NoPriority = 0
|
|
/// - LowPriority = 1
|
|
/// - NormalPriority = 2
|
|
/// - UserBlocking = 3
|
|
/// - HighPriority = 4
|
|
/// - ImmediatePriority = 5
|
|
///
|
|
/// We still have a concept of discrete vs continuous though - discrete events won't be batched, but continuous events will.
|
|
/// This means that multiple "scroll" events will be processed in a single frame, but multiple "click" events will be
|
|
/// flushed before proceeding. Multiple discrete events is highly unlikely, though.
|
|
#[derive(Debug, PartialEq, Eq, Clone, Copy, Hash, PartialOrd, Ord)]
|
|
pub enum EventPriority {
|
|
/// Work that must be completed during the EventHandler phase.
|
|
///
|
|
/// Currently this is reserved for controlled inputs.
|
|
Immediate = 3,
|
|
|
|
/// "High Priority" work will not interrupt other high priority work, but will interrupt medium and low priority work.
|
|
///
|
|
/// This is typically reserved for things like user interaction.
|
|
///
|
|
/// React calls these "discrete" events, but with an extra category of "user-blocking" (Immediate).
|
|
High = 2,
|
|
|
|
/// "Medium priority" work is generated by page events not triggered by the user. These types of events are less important
|
|
/// than "High Priority" events and will take precedence over low priority events.
|
|
///
|
|
/// This is typically reserved for VirtualEvents that are not related to keyboard or mouse input.
|
|
///
|
|
/// React calls these "continuous" events (e.g. mouse move, mouse wheel, touch move, etc).
|
|
Medium = 1,
|
|
|
|
/// "Low Priority" work will always be preempted unless the work is significantly delayed, in which case it will be
|
|
/// advanced to the front of the work queue until completed.
|
|
///
|
|
/// The primary user of Low Priority work is the asynchronous work system (Suspense).
|
|
///
|
|
/// This is considered "idle" work or "background" work.
|
|
Low = 0,
|
|
}
|