Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support :enter and :leave for transformers #114

Closed
ikitommi opened this issue Nov 11, 2019 · 1 comment
Closed

Support :enter and :leave for transformers #114

ikitommi opened this issue Nov 11, 2019 · 1 comment
Labels
enhancement New feature or request for discussion Discussion is main focus of PR

Comments

@ikitommi
Copy link
Member

Currently, the schema-defined transforming functions are all applied before any other transformations. There should be a way to define the order they are run. Interceptors to the rescue?

currently

(m/decode 
  [:and {:decode/string (constantly (partial str "olipa_"))} string?] 
  "kerran" 
  mt/string-transformer)
; "olipa_kerran"

with interceptors

;; function maps to :enter
(m/decode 
  [:and {:decode/string (constantly (partial str "olipa_"))} string?] 
  "kerran" 
  mt/string-transformer)
; "olipa_kerran"

(m/decode
  [:and {:decode/string (constantly {:enter (partial str "olipa_")})} string?]
  "kerran"
  mt/string-transformer)
; "olipa_kerran"

(m/decode
  [:and {:decode/string (constantly {:leave (partial str "_ihminen")})} string?]
  "kerran"
  mt/string-transformer)
; "kerran_ihminen"

(m/decode
  [:and {:decode/string (constantly {:enter (partial str "olipa_")
                                     :leave (partial str "_ihminen")})} string?]
  "kerran"
  mt/string-transformer)
; "olipa_kerran_ihminen"
@ikitommi ikitommi added enhancement New feature or request for discussion Discussion is main focus of PR labels Nov 11, 2019
@ikitommi
Copy link
Member Author

ikitommi commented Nov 11, 2019

maybe even support multiple interceptors via vector syntax?

(m/decode
  [:and {:decode/string (constantly [str (partial str "id_") #(str % "23") keyword]} keyword?]
  "1"
  mt/string-transformer)
; :id_123

rschmukler added a commit to rschmukler/malli that referenced this issue Nov 24, 2019
See the idea surfaced in metosin#114.

This commit introduces interceptor based transformers by using the
`:enter` and `:leave` keys returned on the `-value-transformer`
function.

Naively it uses almost identical implementations for all enter and exit
applications, with the only exception being the collection-based
transformers which do look at the phase to avoid double wrapping
collections.

Ultimately there might be some occassions where we could speed things up
even more (eg. not reducing over a collection if there isn't a mapping
function anyway) but those optimizations don't exist in the current
implementation either, so this PR doesn't attempt to resolve any of
that.
rschmukler added a commit to rschmukler/malli that referenced this issue Nov 25, 2019
See the idea surfaced in metosin#114.

This commit introduces interceptor based transformers by using the
`:enter` and `:leave` keys returned on the `-value-transformer`
function.

Naively it uses almost identical implementations for all enter and exit
applications, with the only exception being the collection-based
transformers which do look at the phase to avoid double wrapping
collections.

Ultimately there might be some occassions where we could speed things up
even more (eg. not reducing over a collection if there isn't a mapping
function anyway) but those optimizations don't exist in the current
implementation either, so this PR doesn't attempt to resolve any of
that.
ikitommi pushed a commit that referenced this issue Nov 28, 2019
See the idea surfaced in #114.

This commit introduces interceptor based transformers by using the
`:enter` and `:leave` keys returned on the `-value-transformer`
function.

Naively it uses almost identical implementations for all enter and exit
applications, with the only exception being the collection-based
transformers which do look at the phase to avoid double wrapping
collections.

Ultimately there might be some occassions where we could speed things up
even more (eg. not reducing over a collection if there isn't a mapping
function anyway) but those optimizations don't exist in the current
implementation either, so this PR doesn't attempt to resolve any of
that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request for discussion Discussion is main focus of PR
Projects
None yet
Development

No branches or pull requests

1 participant