100 lines
No EOL
5 KiB
JSON
100 lines
No EOL
5 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "d47d9edb-4a26-4b1c-8318-698d2aaacb8a"
|
|
}
|
|
],
|
|
"langcode": [
|
|
{
|
|
"value": "en"
|
|
}
|
|
],
|
|
"type": [
|
|
{
|
|
"target_id": "daily_email",
|
|
"target_type": "node_type",
|
|
"target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
|
|
}
|
|
],
|
|
"revision_timestamp": [
|
|
{
|
|
"value": "2025-04-21T01:21:56+00:00"
|
|
}
|
|
],
|
|
"revision_uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"revision_log": [],
|
|
"status": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"title": [
|
|
{
|
|
"value": "The single responsibility principle\n"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2023-05-09T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-04-21T01:21:56+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2023\/05\/09\/the-single-responsibility-principle",
|
|
"langcode": "en"
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>Today, I added a new feature to a project that allows a member to search for a node based on either its title or a specified field on that node, select a result from an autocomplete list and then be redirected to their selected node.<\/p>\n\n<p>I've already implemented this for other node types but needed to do the same for this node type.<\/p>\n\n<p>There are some differences, such as the node type to query for; the additional field depends on which node type as does the text shown in the autocomplete list.<\/p>\n\n<p>To do this, I needed to add a custom block and form, update the <code>AutocompleteController<\/code>, create a new instance of a <code>NodeQuery<\/code> class (a custom class within the custom module), register it as a service and update the <code>SearchQueryFactory<\/code> class.<\/p>\n\n<p>A principle that I follow as much as possible is the single responsibility principle, or SRP (the 'S' in SOLID), where each function or class only has one responsibility - such as returning a response for the autocomplete list, determining the correct node query to use based on the search being run or building the query itself - these are separated and split into their own files.<\/p>\n\n<p>Although more files and functions are created when coding in this way, though they are smaller and more straightforward to work with - which makes them easier to read, debug and maintain. It also makes code like the node query classes reusable as they aren't embedded within a larger class and are easier to test.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>Today, I added a new feature to a project that allows a member to search for a node based on either its title or a specified field on that node, select a result from an autocomplete list and then be redirected to their selected node.<\/p>\n\n<p>I've already implemented this for other node types but needed to do the same for this node type.<\/p>\n\n<p>There are some differences, such as the node type to query for; the additional field depends on which node type as does the text shown in the autocomplete list.<\/p>\n\n<p>To do this, I needed to add a custom block and form, update the <code>AutocompleteController<\/code>, create a new instance of a <code>NodeQuery<\/code> class (a custom class within the custom module), register it as a service and update the <code>SearchQueryFactory<\/code> class.<\/p>\n\n<p>A principle that I follow as much as possible is the single responsibility principle, or SRP (the 'S' in SOLID), where each function or class only has one responsibility - such as returning a response for the autocomplete list, determining the correct node query to use based on the search being run or building the query itself - these are separated and split into their own files.<\/p>\n\n<p>Although more files and functions are created when coding in this way, though they are smaller and more straightforward to work with - which makes them easier to read, debug and maintain. It also makes code like the node query classes reusable as they aren't embedded within a larger class and are easier to test.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
],
|
|
"feeds_item": [
|
|
{
|
|
"imported": "2025-04-21T01:21:56+00:00",
|
|
"guid": null,
|
|
"hash": "74bd5f418ef3374adbd56755b08e95bb",
|
|
"target_type": "feeds_feed",
|
|
"target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
|
|
}
|
|
]
|
|
} |