#builder-pattern #lazy-evaluation #serde #dependency-injection #thread-safe #comments

fieldx_aux

Various types and tools useful for fieldx crates and, potentially, to users of fieldx

9 releases

new 0.1.12 Mar 21, 2025
0.1.11 Mar 21, 2025
0.1.10 Feb 22, 2025
0.1.9 Jan 16, 2025
0.1.3 Aug 2, 2024

#19 in #dependency-injection

Download history 18/week @ 2024-11-27 389/week @ 2024-12-04 34/week @ 2024-12-11 5/week @ 2024-12-18 5/week @ 2025-01-08 137/week @ 2025-01-15 2/week @ 2025-01-29 15/week @ 2025-02-05 256/week @ 2025-02-12 426/week @ 2025-02-19 27/week @ 2025-02-26 4/week @ 2025-03-05 3/week @ 2025-03-12

466 downloads per month
Used in 4 crates (3 directly)

Custom license

89KB
2K SLoC

fieldx_aux

Helper module for the fieldx crate and for any 3rd party crates, extending its functionality.

fieldx itself is heavily based on darling crate which simplifies development of proc-macros quite a lot. But it also imposes some constraints on attribute arguments syntax. This crate aims at overcoming these limitations and providing support for some kinds of attributes required to implement fieldx.

Here is a little break down of what is provided:

  • support for nested arguments, i.e. those that look like arg1("value", trigger, subarg(...))
  • support for some syntax elements that are not on the darling crate menu: some_type(crate::types::Foo), error(crate::error::Error, crate::error::Error::SomeProblem("with details"))[^tuple]
  • a set of types implementing standard fieldx arguments like helpers, or literal values, etc.

[^tuple]: Here, the first argument of error()Error — is an enum; SomeProblem is a variant.

Usage

Let's say we're implementing a field-level attribute foo using darling::FromField trait. And we want it to take these arguments:

  • trigger which would let turn some functionality on or off
  • action to specify a method with special meaning
  • comment with some text
  • vis to specify if field-related code must be public and if yes then what kind of pub we need

A field declaration may take the following form with the attribute:

    #[foo(
        trigger,
        action("method_name", private),
        comment("Whatever we consider useful."),
        vis(pub(crate))
    )]
    bar: usize,

For this we'd need the following declaration somewhere in our proc-macro implementation:

#derive(FromField)
#[darling(attributes(foo))]
struct FooField {
    // ... skipping some darling-default fields ...

    trigger: Option<FXBool>,
    action: Option<FXHelper>,
    comment: Option<FXString>,
    vis: Option<FXSynValue<syn::Visibility>>,
}

That's all, this crate will take the burden of implementing the arguments from you!

Dependencies

~0.6–1MB
~23K SLoC