-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
User page: new following section #1750
User page: new following section #1750
Conversation
…ps of 10 interests. Inserted interests in columns.
@voodoorai2000, @bertocq, @decabeza ahí va otro pull-request desde la playa! 😄 Esperamos vuestros comentarios. Falta la verificación de la funcionalidad por parte de Yago Bermejo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one 😃 👍
Some comments on the side just to improve code readability and a question that might be easy to explain
|
||
load_and_authorize_resource | ||
helper_method :author? | ||
helper_method :author_or_admin? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't really understand the reason to remove author_or_admin?
method and its usage, can you explain a bit further? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bertocq The main reason is that apparently it was not being used anywhere in the application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 you're right, I did a project search and no use, although sometimes looking for the method string is not enough if you do compose de method name with a string interpolation like send("#{this}_or_#{that}")
but that's not the case I guess based on the specs passing ^_^
Nice catch & cleanup 👏 😄
app/helpers/follows_helper.rb
Outdated
end | ||
|
||
def entity_icon(entity) | ||
case entity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered the option to use a hash here instead of a case statement? Something like:
def entity_icon(entity)
{
'Proposal' => 'proposals',
'Budget::Investment' => 'budget'
}[entity]
end
It could be improved by moving the hash to a constant variable, or even switching keys for values to use new hash syntax:
def entity_icon(entity)
{
proposals: 'Proposal',
budget: 'Budget::Investment'
}.invert[entity]
end
Last but not least, it seems odd that "proposals" is plural but "budget" is singular 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like very much this option! Less words and same clarity always better!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the plurals question... don't worry @Senen I just realized it was wrong on consul beforehand :) I'll fix it afterwards this PR is merged! 👍
@@ -50,7 +50,7 @@ def initialize(user) | |||
can :create, Budget::Investment, budget: { phase: "accepting" } | |||
can :suggest, Budget::Investment, budget: { phase: "accepting" } | |||
can :destroy, Budget::Investment, budget: { phase: ["accepting", "reviewing"] }, author_id: user.id | |||
can :vote, Budget::Investment, budget: { phase: "selecting" } | |||
can :vote, Budget::Investment, budget: { phase: "selecting" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^_^ /bertocq likes this
@@ -0,0 +1,28 @@ | |||
<tr id="proposal_<%= proposal.id %>"> | |||
<td> | |||
<%= link_to proposal.title, proposal, proposal.retired? ? { class: 'retired' } : {} %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that ? { class: 'retired' } : {}
:) I think I have added some class=""
around :( couldn't figure out this was the way 👏
app/views/users/_proposal.html.erb
Outdated
</td> | ||
<% end %> | ||
|
||
<% if author?(proposal) || proposal.retired? %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me a bit to understand all the conditionals around this block and realize there is only 2 scenarios. Maybe this could be easier to read:
<% if proposal.retired? %>
<td class="text-center">
<span class="label alert"><%= t('users.proposals.retired') %></span>
</td>
<% elsif author?(proposal) %>
<td class="text-center">
<%= link_to t('users.proposals.retire'),
retire_form_proposal_path(proposal),
class: 'button hollow alert' %>
</td>
<% end %>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree @bertocq! We will make this change too!
@@ -46,7 +46,7 @@ | |||
<p><%= t('users.show.private_activity') %></p> | |||
<% end %> | |||
|
|||
<% if @user.public_interests || @authorized_current_user %> | |||
<% if valid_interests_access? %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch!
app/helpers/follows_helper.rb
Outdated
@@ -52,6 +52,18 @@ def unfollow_drop_id(followable) | |||
"unfollow-drop-#{entity_full_name(followable)}-#{followable.id}" | |||
end | |||
|
|||
def entity_title(title) | |||
entity = title.gsub('::', '/').downcase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you'll love this page http:https://inflector.me/Budget::Investment :)
This two lines could be just one t("activerecord.models.#{title.underscore}.other")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this resource. 😄 👏. I'll do this change.
app/views/users/_following.html.erb
Outdated
<table> | ||
<tbody> | ||
<% @follows.where(followable_type: followable_type).each do |follow| %> | ||
<% if followable_type == "Proposal" %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After seeing both entity_title
and entity_icon
helper methods. I think a third one could be nice to avoid spilling == "Proposal"
and == "Budget::Investment"
on a view :D, seems tricky to remember if another entity becomes as well "followable"
So the entire if-else could be replace for something like:
<%= render entity_partial(followable_type), entity_partial(followable_type).to_sym => follow.followable %>
Being the helper function at app/helpers/follows_helper.rb
:
def entity_partial(title)
title.parameterize.gsub('-','_')
end
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes @bertocq while we were programming exactly your solution we thought that this abstraction forces the developer to follow entity_partial helper method to understand where to put and how to name new followable object partials. Because of that we decide to let these lines explicitly written, but if you prefer, we can make this change in a second. I think both solutions has some disadvantage and in this case we prefer explicitness over reducing code lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the scenario were another entity becomes followable, for both icon and title translation following the trail to the helper will be needed, so I don't see it as a big downside to the proposed refactor. I just imagine 4-5 entities being followable and the if-elsif-elsif.. being too big when just following a simple convention (that also complains with how rails expects things to be named) could make it easier.
But thats like you say its a subjective matter, I prefer conventions over more lines, maybe @voodoorai2000 can take a look and say if he has a hard opinion about it or not.
4c4dd54
to
57c8887
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems really great to me 👍 😃 & thanks for taking in consideration the suggestions!
app/helpers/follows_helper.rb
Outdated
@@ -9,23 +9,22 @@ def show_unfollow_action?(followable) | |||
end | |||
|
|||
def follow_entity_text(followable) | |||
entity = followable.class.name.gsub('::', '/').downcase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏 nice cleaning up on the side! 💪
@bertocq thanks for all your advices! They are allways welcome! 😃.We are still waiting customer validation. We'll let you know when it's done. |
app/views/users/_following.html.erb
Outdated
@@ -0,0 +1,31 @@ | |||
<ul class="accordion" data-accordion data-allow-all-closed="true"> | |||
|
|||
<% @followable_types.each do |followable_type| %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey,
I just sent you a small PR regarding this, hope you like it :)
Regarding the concept of
for something like this:
|
Minor refactoring for follows
<table> | ||
<tbody> | ||
<% follows.each do |follow| %> | ||
<%= render_follow(follow) %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@voodoorai2000 nice refactor! 😍
…ows helper. Rename entity to followable.
…ble_button partial to follow_button.
…der notice on AJAX JS response.
@voodoorai2000, @bertocq, @decabeza i think we finally have final version. I made all suggested changes by @voodoorai2000 and removed unused translation key, also we removed popup on follow buttons and add a notice message to keep user informed. Off course we increased tests coverage with new notice checks and delete a lot of ugly code needed by popup but useless now. As always, thanks for your advices. 😃 I add a link to our staging server so you can try look and feel easily. |
…owed_by? on followable model concern. Some code improvements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome
@bertocq, @voodoorai2000, @decabeza this feature was approved by Yago. We can merge it! 😃 |
…-processes Draft phase on legislation processes
What
Show user followable activity on public user page.
Refactor
How
Add new tab to show followed objects by user.
Screenshots
Refactor screenshots
Test
Increased test coverage to:
Deployment
As usual.