-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Catalog ProductList helper has coupling to Registry #27119 #27648
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
Catalog ProductList helper has coupling to Registry #27119 #27648
Conversation
Hi @mcspronko. Thank you for your contribution
For more details, please, review the Magento Contributor Guide documentation. |
Hi @mcspronko. Thank you for your change, it's really cool. Unfortunately, I have not very good news here. After the internal discussion, the conclusion was the following. I'm adding @lenaorobei to the thread for more details. |
@rogyar I can make it backward compatible if this an issue for 2.4. But as far as I am aware, the module-catalog major version is going to be increased. Please confirm |
Dear @rogyar I appreciate you are looking into it. |
Hi @mcspronko. Thanks a lot for the adjustments. Could you take a look at the red static tests, please ("Static tests for B2B" to be precise)? There are some issues that need to be addressed. Some of them are not directly related to your changes but if you have a chance to make it green, it will be awesome. As a rule, the static code analysis issues are pretty minor like missing descriptions or so. Please, let me know if you need any help from my end. |
Hi @rogyar Please advise what should we do with the failing functional tests, that I believe is somehow random. Here is the output.
Also, the Semantic Version Checker is red, due to the removal of the optional |
@magento run all tests |
I see the same functional test failing for other PRs. So, it's not related to the current change somehow. |
Since you have didn't introduce a new functionality, there's no necessity for creating functional/integration tests. However, if you could cover the newly introduced classes by unit tests, it would be awesome (you will get extra points for that as well). Thank you! |
@rogyar, please review the latest changes. |
/** | ||
* @var ScopeConfigInterface|MockObject | ||
*/ | ||
private $scopeConfig; |
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.
Currently, we are advocating suffixing mocks with the Mock
keyword. So, it's easier to differentiate mocks and real objects through the test. It's not a requirement, but if you could follow this practice, I would appreciate it.
private $scopeConfigMock;
private $toolbarConfigMock;
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.
@rogyar no problem at all. Can you please refer to documentation to read more about the Mock
suffix?
Thank you in advance.
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.
Unfortunately, there's no documentation that explicitly describes the best practices for creating unit tests in DevDocs so far. But we are working on the topic on that matter.
* | ||
* @return string | ||
*/ | ||
public function getOrderField(): string |
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 was thinking how to improve this implementation to be simpler and easier to follow. Here's an equivalent version that avoids duplication of the default behavior.
try {
$category = $this->currentCategory->get();
if ($category->getDefaultSortBy()) {
return $category->getDefaultSortBy();
}
} catch (NoSuchEntityException $exception) {
// Fall back to the default configuration
}
return $this->categoryConfig->getDefaultSortField();
I think, in most cases it's better to keep the "positive" logic inside try..catch
as it guarantees that all its preconditions are met (variable $category
is defined in this case). Such code is also easier to follow as the sequential logic is grouped together.
@engcom-Alfa Thank you in advance. |
cc: @rogyar |
Hi @mcspronko. Could you merge the latest 2.4-develop changes to your branch and run the tests, please? Thank you! |
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.
Hi @mcspronko,
Could you merge recent changes and run the tests again or give us permissions to do so? Unfortunately we don't have permissions for doing that instead of you.
@magento run all tests |
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.
Hi @mcspronko,
Could you review and fix failing tests?
@ihor-sviziev I opened tests and I don't see what can be fixed. |
@magento run all tests |
@mcspronko could you merge recent changes from 2.4-develop branch? Sometimes outdated branch causing test failures |
*/ | ||
private $toolbarConfig; | ||
|
||
protected function setUp() |
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.
Following change broke the tests. Please fix it like this:
protected function setUp() | |
protected function setUp(): void |
@@ -173,11 +192,11 @@ public function testGetPagerEncodedUrl() | |||
|
|||
$this->urlBuilder->expects($this->once()) | |||
->method('getUrl') | |||
->willReturn($url); | |||
->will($this->returnValue($url)); |
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.
Please revert such changes in all places
$this->urlBuilder = $this->createPartialMock(Url::class, ['getUrl']); | ||
$this->scopeConfig = $this->getMockForAbstractClass(ScopeConfigInterface::class); | ||
$this->scopeConfig = $this->createMock(ScopeConfigInterface::class); |
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 any reason for this change?
@@ -7,19 +7,21 @@ | |||
|
|||
namespace Magento\Catalog\Test\Unit\Block\Product\ProductList; | |||
|
|||
use PHPUnit\Framework\TestCase; |
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 like earlier all imports were sorter, while now they're not. Could you run optimize imports in phpstorm for all changes files and commit?
*/ | ||
public function __construct( | ||
ScopeConfigInterface $scopeConfig, | ||
Registry $coreRegistry = null | ||
ToolbarConfig $toolbarConfig |
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.
This class marked as @api
, so we can't just replace existing argument with a new one. Please introduce new dependecy as optional argument
@magento run all tests |
Unit tests failure:
|
Hi @mcspronko, |
@mcspronko I am closing this PR now due to inactivity. |
Hi @mcspronko, thank you for your contribution! |
Description (*)
In this pull request the Magento\Framework\Registry class dependency is removed from the Magento\Catalog\Helper\Product\ProductList class.
The new Magento\Catalog\Model\Category\Toolbar\Config class has been added to provide access to the Sort By (Order Field) value.
The getOrderField() method checks if the current category has the default_sort_by value, and returns it, the default configuration value is returned otherwise.
Fixed Issues (if relevant)
Manual testing scenarios (*)
Contribution checklist (*)