Skip to content

Reactive Variables Implemented to Concept Design

Let's say we have the following app for calculating salaries at a work place.

concept User
state:
    user: set User
    username: User -> one String

concept Profession<User>
state:
    profession: User -> one Profession

concept Pay<Profession>
state:
    basePay: Profession -> one Integer
    hourlyPay: Profession -> one Integer

concept HourTracker<User>
state:
    hoursWorked: User -> one Integer
concept User
state:
    user: set User
    username: User -> one String

concept Profession<User>
state:
    profession: User -> one Profession

concept Pay<Profession>
state:
    basePay: Profession -> one Integer
    hourlyPay: Profession -> one Integer

concept HourTracker<User>
state:
    hoursWorked: User -> one Integer

Then we could write a action that could calculate the pay received by any user as an syncronization of all the actions above. (Here, I directly accessed the state of concepts or assumed some actions exists for simplicity, but they are hopefully simple enough that it should make sense).

function getPay(username):
    const user = User.getbyUsername(username);
    const profession = Profession.profession[user];
    const basePay = Pay.basePay[profession];
    const hourlyPay = Pay.hourlyPay[profession];
    const hoursWorked = HourTracker.hoursWorked[user];
    const pay = basePay + hourlyPay*hoursWorked;
    return pay;
function getPay(username):
    const user = User.getbyUsername(username);
    const profession = Profession.profession[user];
    const basePay = Pay.basePay[profession];
    const hourlyPay = Pay.hourlyPay[profession];
    const hoursWorked = HourTracker.hoursWorked[user];
    const pay = basePay + hourlyPay*hoursWorked;
    return pay;

To me, this looks very similar to the reactive variable model we saw in lecture. There are variables, that depend on each other in an DAG formation, and updates to any variables also updates the variables that depend on it.

Of course, the main difference is that in frontends all updates should be very fast to calculated variables for the user experience, but I think there are some merits to thinking of the backend this way as well.

Firstly, all the intermediate variables calculated in this function are very useful on their own as well, so maybe we want them to be a part of our api. Of course we can achieve this by adding functions like getProfession(username), getHourlyPay(username), etc... Then, to avoid code repetition, we could call these new functions from getPay. But in this scenario, we would have to calculate some variables multiple times (user and profession in this example). It seems to me there is a tradeoff between reducing code repetition and increasing performance. Maybe there is a third better way to do things?

Secondly, thinking of this DAG structure of variables depending on each other could make debugging lot easier. If you have an error when accessing a value, just go down the DAG to see where the errors could be.