-
Notifications
You must be signed in to change notification settings - Fork 7
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
[DEV APPROVED] 7938 resize promo article images #1691
Conversation
This PR as it stands is a 👎 from me. Whilst the end result (as seen in the "Files changed" tab) looks good, the narrative that plays out in each commit is not. There's code and images that get added and then removed again (which is fine during dev, but should be rebased out before issuing a PR), and the individual commits could do with better explanations. I think it needs to be reworked so that it is one or two good commits. If you're not sure how, I'm happy to pair with you to make it better. |
Please to not merge until have you've had a chance to pair with Norm on how to improve the structure. |
e5378d2
to
dde43c3
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.
What's with the asterisks in the commit message?
|
||
attributes | ||
hsh |
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.
What is the purpose of renaming this?
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.
@norm This is to avoid overloading the method name. I will change it to something more meaningful
dde43c3
to
2ecdc67
Compare
<%= image_tag(item['image'], alt: '', class: 'promo__img') %> | ||
<%= image_tag(item['image'], | ||
alt: '', | ||
sizes: '(max-width: 479px) 100vw, (max-width: 959px) 50vw, 25vw', |
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.
Is the view the best place to define this sizes attribute?
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.
@tomas-stefano it's used nowhere else but here. Where is the best place to put this or what is the best practice on handling this, please?
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.
Ok. Is this line very important for the whole feature? What happen with the functionality if I remove this line?
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.
@tomas-stefano If that line is removed the srcset will not work at the viewports which we expect them to be activated.
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.
So, if you remove this line ... will the tests fail to indicate that the feature is not working properly?
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.
The tests will not fail neither will there be any catastrophic failure. Are you advocating the addition of a test?
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 am not advocating anything. In order to give you the info on the best place to put this line, I need to understand all the implications of it. That's the point of my questions. But I didn't understand one thing: you said that if this line is removed the srcset will not work at the viewports and in the other you said there will not be any catastrophic failure. Could not be catastrophic, but is still a failure and the functionality will not work as expected ... right?
end | ||
|
||
describe '.translate_attributes_from_raw_blocks' do | ||
let(:hsh) do |
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.
Can it be renamed to hash, please? IMHO abbreviation it is only useful when it is very very long word.
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.
Actually, it can be renamed by blocks attributes or even page content itself. Or event the response body (if it is the faked response from CMS)
end | ||
|
||
describe '.group_nested_attributes' do | ||
let(:hsh) do |
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.
Can it be renamed to hash, please? IMHO abbreviation it is only useful when it is very very long word.
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.
Actually, it can be renamed by blocks attributes or even page content itself.
@@ -12,23 +12,21 @@ def self.build(response) | |||
end | |||
|
|||
def attributes | |||
attributes = response.body | |||
attrs = response.body |
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.
Is there a reason to abbreviate to attrs?
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.
@tomas-stefano it is abbreviated to attrs as the next best alternative attributes is already used as the method name. Due to how it's heavily used by other methods, it's best to keep the sentiment of attributes even if it's in an abbreviated form.
30 def set_title_from_label(attributes)
31 attributes['title'] = attributes['label']
32 end
33
34 def set_body_from_content_block(attributes)
35 attributes['body'] = BlockComposer.new(attributes['blocks']).to_html
36 end
37
38 def set_description(attributes)
39 attributes['description'] = attributes['meta_description']
40 end
41
42 def set_categories(attributes)
43 attributes['categories'] = attributes['category_names']
44 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.
Ok, I understand that is heavily used, but it is mutating the same object, so the names could be the same without any problem. I would return to attributes as before because the code becomes better to read.
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.
@tomas-stefano I did something like this and @norm had other ideas. I can see why both your ideas are viable. I need a second opinion on this. I am torn between whether to overload the method name or not.
@jriga wdyt, please?
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.
@Tr4pSt3R I think you're confusing your notes from our pairing session. My comment on not overloading variable names was based on a piece of code where you reused a variable to contain two different values (that I don't like). This was fine.
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 just wanted to say I'm so proud of all of you right now. 😍
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 clarifying @norm.
Thanks for pointing that out @tomas-stefano.
@@ -1,7 +1,87 @@ | |||
# coding: utf-8 |
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.
Is this line really need it?
module Core::Repository::CMS | ||
RSpec.describe AttributeBuilder do | ||
let(:body) { File.read('spec/fixtures/cms/beginners-guide-to-managing-your-money.json') } | ||
let(:response) { OpenStruct.new(body: JSON.parse(body)) } | ||
let(:ab) { AttributeBuilder.new(:resource) } |
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.
Can we rename to attribute_builder, please?
let(:ab) { AttributeBuilder.new(:resource) } | ||
|
||
describe '.set_title_from_label' do | ||
let(:hsh) { { 'label' => :foo } } |
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.
Is this hsh variable the response body? If so, can we rename to response_body?
why was the gem rb-readline being added then removed in the last two commits? also could do with a bit more detail in the commit message |
@pmcostello it's a fixup commit so git automatically adds a commit message to indicate that it's a temporary commit.
There will no trace of it in the final commit. |
looks good to me, just needs |
ok thanks for the explanation @Tr4pSt3R, squash and merge 👍 |
7e66b81
to
068305c
Compare
👍 |
I don't want to sound picky, but please correct if am wrong. Since my understanding of the code that I read:
Correct if I am wrong but without any of these, the whole feature will not work properly. RIght? Conclusion: There is no test that indicates the srcset attribute coming from the cms or even a test to add an expectation the sizes attribute on img tag on the high level spec. I saw here that for the tag you added a helper and the helper spec but I still think that we can test in a high level test (a view spec or even a cucumber spec). There are some examples on the app for view specs too: https://github.com/moneyadviceservice/frontend/blob/master/spec/views/header_sign_in_box_spec.rb Or there are examples of cucumber specs that uses VCR to make the request to CMS too on the features dir. Can we not add a view spec or a cucumber spec for this feature? |
@tomas-stefano have you looked here and here? I have put it in [WIP]. Here is a view spec that tests the image srcset size property. The attribute srcset has been tested in this file spec/lib/core/repository/cms/attribute_builder_spec.rb. See here |
Since what I saw on the test, the view spec is not testing neither the srcset nor the sizes attribute on img tag. Or there is no integration test that makes the request to the CMS and asserts the the insertion of the srcset attribute (based on the CMS request) and add the sizes attributes as well. I think it is best we talk in person and pair together on the subject. |
spec/views/resize_image_spec.rb
Outdated
|
||
allow(view).to receive(:items_without_image) do | ||
[{"heading"=>"Estimate the cost of buying a house and moving", "url"=>"https://example.com/blog", "content"=>"There is more to it than just mortgage repayments"}] | ||
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.
Can you run rubocop, please? I would fix this identations.
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.
@tomas-stefano Rubocop is now passing for this file Thanks.
* Adds the ability to pull in dynamic srcset properties from the CMS Homepage API. Browsers that support image srcset will serve the right images based on the device that calls the page. * The attribute builder returns the srcset property
65cc25b
to
9d20475
Compare
I thought about adding a Cucumber spec but it won't achieve anything so I will leave it. The view spec provides sufficient coverage for this. |
Thank you for pairing. But now the view spec is testing the core feature and if you remove the tests will fails, exactly what we expected. Saying that, good work mate! 👍 👍 🚢 |
The main work on the CMS side to enable this feature can be seen here: moneyadviceservice/cms#383
View Card on Target Process
This change is