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

Expose component parameters for static inspection/tooling/editing #9

Open
sgrove opened this issue Aug 2, 2015 · 0 comments
Open
Assignees

Comments

@sgrove
Copy link
Member

sgrove commented Aug 2, 2015

Similar to Sul or Om/next.
Just a rough sketch of what it might look like:

(defn my-com [data owner opts]
 (reify
   dato/IParams
   (params [_]
     {:tasks {:qes-by :task/title}
      :me {:qe-by :user/me? true}
      ;; Bit tricky w/ dep graph, something like prismatic fnk might enable this
      :local-session {:qe-by :session/user-id my-id}
      :filtered-task-ids {:q '[:find ?eid :in $ ?title-filter :where [?eid :task/title (re-match ?title-filter)]
      :current-company {:entity company-eid}
      :cases {:entities [case-eids]})
   dato/IRender
   (render [_]
     (let [data (dato/com-data owner)]
       ....))
  1. The inputs required to instantiate my-com would be {:company-eid ... :title-filter #"..." :case-eids [...] :my-id ...} (and the current db at render time),
  2. the value of data in render would have the same structure as specified in IParams

Other completely dynamic queries could be done in the render method if necessary, but whereas with the above format we can take care of (however inefficiently) automatically updating the component, it would the be up to the developer to make sure that listeners were added/removed on IWillMount and IWillUnmount for said dynamic queries.

@sgrove sgrove self-assigned this Aug 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant