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

Calculated properties question #28

Closed
michshat opened this issue May 29, 2016 · 2 comments
Closed

Calculated properties question #28

michshat opened this issue May 29, 2016 · 2 comments

Comments

@michshat
Copy link

Quick question, is it possible to calculate new properties based on new properties - what would be the approach, in the example below the c doesn't get passed in as a context to d

export const SUM = {
  augment: L.augment({       
    c: ({a, b}) => a + b,
    d: ({c}) => c + 2  
  }), 
  a: R.prop("a"),
  b: R.prop("b"),
  c: R.prop("c"),
  d: R.prop("d")  
}
@polytypic
Copy link
Member

First of all, I would encourage avoiding augment unless you really need it. It can be handy, but IME it is rarely needed. If you are using augment heavily, you may be missing out on other ways to organize your code. If you are using augment on a model stored in an atom, you can just create separate observable properties instead of using augment.

Note that you can compute multiple extra properties as an object:

L.augment({extra: ({a, b}) => {
  const c = a + b
  const d = c + 2
  return {c, d}
}})

The current implementation of augment intentionally restricts the parameter to be the original unaugmented object. I was under the impression that the order in which object properties are enumerated in JS is undefined, which would make it easy to write bugs if the semi-augmented object were passed in. However, googling more on this I get the impression that it might now be defined in ES2015. It seems difficult to get a really authorative answer on this and as I currently have fever, I'm not going to go and read the JS spec legalese. :) But, it would seem like there is a case for changing the definition of augment so that one can exploit property enumeration order. I'll have to look in to this when I get better.

@michshat
Copy link
Author

Appreciate the feedback and sorry about the fever - speedy recovery!

Here is my example that uses car lease calculations, I'm all for avoiding augments :), but what you suggest fits better for this design:

export const SUM = {
  augment: L.augment({extra:({CarPrice, Downpayment, CostAddedtoLease, Term, HST, InterestRate, ResidualValuePercent}) =>{
    const CapCost = CarPrice - Downpayment + CostAddedtoLease
    const ResidualValueDollar = CarPrice * ResidualValuePercent / 100
    const Depreciation = (CapCost - ResidualValueDollar) / Term
    const Finance = (CapCost + ResidualValueDollar) * (InterestRate/2400)
    const MonthlyPayment = Depreciation + Finance
    const TotalMonthlyPayment = MonthlyPayment + (MonthlyPayment * (HST/100))   

    return {CapCost, ResidualValueDollar, Depreciation, Finance, MonthlyPayment, TotalMonthlyPayment}
  }}),  
  CarPrice: "CarPrice",
  ScenarioName: "ScenarioName",
  id: "id",         
  Downpayment: "Downpayment",
  CostAddedtoLease: "CostAddedtoLease",  
  ResidualValuePercent: "ResidualValuePercent",  
  Term: "Term",
  HST: "HST",
  InterestRate: "InterestRate",
  CapCost: R.prop("CapCost"),
  Depreciation: R.prop("Depreciation"),
  Finance: R.prop("Finance"),
  MonthlyPayment: R.prop("MonthlyPayment"),
  ResidualValueDollar: R.prop("ResidualValueDollar"),
  TotalMonthlyPayment: R.prop("TotalMonthlyPayment"),    
  CreateDate: "CreateDate",
  ChangeDate: "ChangeDate" 
}

Also how the extra property would be referenced from the control - like this K(item, M.SUM.extra.CapCost)

Really appreciate the framework and your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants