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

Make auto-detecting permitted next nodes the default behaviour #2374

Merged
merged 49 commits into from
Mar 18, 2016

Conversation

floehopper
Copy link
Contributor

In #2368 & #2370, all occurrences of next_node with a block were converted to use the automatic detection of permitted next nodes instead of explicitly supplying them. So we can now make the code less verbose by making permitted: :auto the default arguments for next_node with a block.

Note that the old mechanism is still available, it's just no longer the default behaviour.

I've updated the documentation to reflect this change, noting that the old approach is now deprecated.

Motivation

This is another small step towards simplifying the flow DSL and in particular the code in SmartAnswer::Question::Base.

Internal changes

Before

next_node(permitted: :auto) do |response|
  if response == 'green'
    question :green?
  else
    outcome :red
  end
end

After

The permitted: :auto is no longer necessary:

next_node do |response|
  if response == 'green'
    question :green?
  else
    outcome :red
  end
end

External changes

This is just a refactoring - there should be no changes in externally observable behaviour.

@floehopper
Copy link
Contributor Author

I'm going to rebase this against master to resolve the conflicts that have been introduced by recent changes in master and then force-push it.

@floehopper floehopper force-pushed the make-autodetecting-permitted-next-nodes-the-default branch from ddf43bf to 6105b1e Compare March 18, 2016 10:18
@floehopper
Copy link
Contributor Author

Rebasing & force-pushing done. Conflicts resolved. Ready for review again.

@@ -8,7 +8,7 @@ class QuestionBaseTest < ActiveSupport::TestCase
context '#next_node' do
should 'raise exception if called with block but no permitted next nodes' do
e = assert_raises(ArgumentError) do
@question.next_node do
@question.next_node(permitted: []) do
:done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this line be?

outcome :done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, although I see why you ask. This is still testing the "old" mechanism which doesn't require the wrapping of the result with question or outcome. I hope to remove this functionality soon.

@erkde erkde self-assigned this Mar 18, 2016
@erkde
Copy link
Contributor

erkde commented Mar 18, 2016

Even though this code doesn't change the outward appearance of any page, it might be useful to add a before and after of what a next_node block looked / will look like, with this change.

@floehopper
Copy link
Contributor Author

I've edited the PR description to explain the internal changes to the flow DSL.

end
assert_equal [:done, :another_question], @question.permitted_next_nodes
end
end
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: In the context description, when I read "not permitted option specified" I'm looking for the 'not permitted' option, but I guess it means without a permitted option.

Minor: In the should description, I'm not sure I'm aware of what syntactic sugar methods relates to. I think a more obvious expectation would be that it expects to return a list of nodes from the outcomes and questions defined within the block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding your first comment - that was a typo - well spotted! Fixup commit: 30d92cc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding your second comment - I've tried to improve the test name. Fixup commit: 7c9ea42.

@floehopper
Copy link
Contributor Author

@erikse: Thanks for reviewing. I've addressed your comments. Are you happy for me to merge this?

@erkde
Copy link
Contributor

erkde commented Mar 18, 2016

Yep, this looks really good

@erkde erkde added the LGTM label Mar 18, 2016
@floehopper
Copy link
Contributor Author

Thanks. I'll get it rebased, force-pushed & merged.

@floehopper floehopper force-pushed the make-autodetecting-permitted-next-nodes-the-default branch from 7c9ea42 to e19a506 Compare March 18, 2016 11:35
floehopper added a commit that referenced this pull request Mar 18, 2016
…ext-nodes-the-default

Make auto-detecting permitted next nodes the default behaviour
@floehopper floehopper merged commit 5fcc42d into master Mar 18, 2016
@floehopper floehopper deleted the make-autodetecting-permitted-next-nodes-the-default branch March 18, 2016 11:39
floehopper added a commit that referenced this pull request Mar 18, 2016
I missed these two occurrences when I rebased this commit [1] in #2374.

This happened because they were converted from `next_node(:key)` to
`next_node do ... end` in #2367.

[1]: acb4f53
floehopper added a commit that referenced this pull request Mar 18, 2016
floehopper added a commit that referenced this pull request Mar 18, 2016
floehopper added a commit that referenced this pull request Mar 18, 2016
In #2374 automatic detection of permitted next nodes was made the default and
all the places where `next_node` was called with explicitly specified permitted
next nodes were converted to use this syntax.

This commit removes the `permitted` option altogether which should prevent any
regressions from creeping in.
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

Successfully merging this pull request may close these issues.

2 participants