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

refactor:Extract function for message being in a narrow #902

Merged

Conversation

neiljp
Copy link
Collaborator

@neiljp neiljp commented Jan 31, 2021

This could do with a unit test, though it's just a refactor right now and the tests would potentially cover a large state space.

I'm thinking this could be useful in many ways right now already as an available method that could be used in various places.

@zee-bit Could this be useful for #824 if you constructed a fake message dict to pass in?

@zulipbot
Copy link
Member

Hello @zulip/server-refactoring members, this pull request was labeled with the "area: refactoring" label, so you may want to check it out!

@zulipbot zulipbot added the size: L [Automatic label added by zulipbot] label Jan 31, 2021
@neiljp neiljp added the PR ready to be merged PR has been reviewed & is ready to be merged label Feb 1, 2021
@zee-bit
Copy link
Member

zee-bit commented Feb 1, 2021

@neiljp Thanks for opening this PR. This could potentially be useful for #824, considering I was currently constructing a fake narrow list there, instead of message dict. I can definitely see how we can construct a message dict(from request and narrow) as an argument for this function as well. For simplicity and reusability, I can make a function that constructs a fake message dict using requests & narrow, and then pass its output to this function.

However, I still see both the functions to be particularly similar, considering the only difference would be that the function in #824 has its use-case limited to just notifying the user if the message is not from the same narrow, whereas this function could be used in various places that need this particular logic including that PR. Is there any other difference that I may have missed?

@neiljp neiljp merged commit b9a269e into zulip:main Feb 2, 2021
@neiljp neiljp modified the milestones: 0.6.0, Next Release Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: refactoring feedback wanted PR ready to be merged PR has been reviewed & is ready to be merged size: L [Automatic label added by zulipbot]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants