1. 7
    Transition State based on Existing State using the State ADT
    5m 31s

Transition State based on Existing State using the State ADT

Share this video with your friends

Social Share Links

Send Tweet
Published 6 years ago
Updated 6 years ago

While sometimes outside input can have influence on how a given stateful transaction transitions, there are many times where the current state at the time of a transaction. We can see the power of this type of transaction by seeing what it would take to read from two different locations in state in parallel and then pass on the result of combining them under a comparison operation to another transition that will set a different location based on the result.

Instructor: [00:00] In our initial state we have this is correct attribute, which we would like to set to true or false depending on if the hint provided in this hint attribute matches a card selected from this cards array.

[00:13] We'll first need a way to set the value in is correct, so we pop over to our feedback model and export a new state transaction as a function called set is correct that will take in an is correct Boolean value. We'll define said is correct as a function that takes a Boolean to our beloved state app state of unit.

[00:36] To implement, we reach for this over helper, pointing at our is correct key. We'll use the crock's constant function that returns a function that always gives back the value it was loaded with. The setting is correct to the value we were called with.

[00:49] Now we should take this little bugger for a spin and see what this transaction will do for us. We need to import in set is correct from our feedback module located at data model feedback. Down in the depths of our index file, we pass our log function, the result of calling set is correct with false.

[01:10] See, we get back a state instance which we then run using exec with our initial state and observe that is correct is marked false. With true marking it is true. Now that we can set is correct, we need a function in our feedback module that validates a player's answer against the current hint. We'll call it validate answer.

[01:32] We define validate answer as a function that takes a given string to a state app state of Boolean. To implement, we reach for the crock's converge function that branches an input into two paths and merges them into one final answer.

[01:48] We'll merge our paths with a two, combing them with this equals function, comparing the results of get hint and get card. Converge passes its argument to both get hint and get card, which in our case is going to be the ID of the card the player answers with.

[02:06] To see this in action, we call an imported validated answer, passing an ID of green square and run the result with the val width to peak at the result int. With a quick save we see we get back false, even though we were expecting true. To see what could be causing this we look at the sigs for our state functions and we see get hint returns a hint while get card returns a card.

[02:30] In order to compare apples to apples, we need to convert a card to a hint, which we'll do with the helper that will call card to hint that will take an ID as its input. We define card to hint as a function that takes a string to a state app state of hint. To implement we use get card to pull our card just like before, but this time we'll map the crock's omit function that removes a list of keys from a given object, ID in our case, to convert a card to a hint.

[03:01] Now down in validate answer we just swap out get card with card to hint and observe we're getting our expected result of true. An answer of orange square gives us false and the same goes for a non-existent purple star. Now that we have a working flow, let's see about ways we can implement in a more point free style.

[03:22] First let's put back our valid answer and pop into feedback where we'll convert card to hint into a composition that maps our omit function that removes the ID from the object that resides in the result after a call to get card, which pulls the card from our cards array.

[03:40] With a little housekeeping and some nail care emoji we can clean this up to make it easier on the eyes of future us, putting each step in this composition on its own line. Future us will thank us. Popping back into index, we verify that the flow still works as expected with the false blue square and our valid green square.

[04:00] To keep cognitive low down on future us, we'll introduce this helper called lift state that takes a function A to B, then in A and returns us a state as a B. It takes a function FN and composes it with a call to state dot of, lifting the result of FN into a state instance, giving us a Kleisli arrow.

[04:19] Now that we have a means to create a Kleisli, we can change this compose into a compose K and replace this map function with our lift state, keeping it Kleisli all the way down. Again, we verify equivalents in index with a false orange square and a truthy green square.

[04:36] We now have all the pieces of our feedback puzzle. Let's put it all together by creating a feedback function, which we define as a function that takes our string ID and gives us back the all too familiar state app state of unit.

[04:51] Implementation is just using compose K to combine our two transitions sequentially by setting our is correct attribute with the result of our answer validation. With no need to expose anything else in this file, we export feedback as the default and just pop back to index, pulling the default and assigning it to feedback, which we'll use downstairs to take a peek at the resultant by swapping it with the old validate answer, getting our expected unit in the resultant.

[05:20] With a quick change to exec with, we see that we did in fact transition our state as expected with is correct set true while a false blue square sets it to false.

egghead
egghead
~ 2 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today