Answers.Body: <p>Im not totally sure about this, but you can just use the 'with' eager loading specifier even if the field does not exist in the blocks created. So imagine the client made a text block, another textblock and some other block it should not give an error if you use with([block:someImageField]).</p>
  <p>Again, im not 100% sure if this works correctly</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-09T13:17:31.153Z
Answers.Text: Well, I would do this, except I'd have to populate each and every query with about 50 fields, which doesn't seem like optimization, quite the opposite...
Answers.UserDisplayName: InanisAtheos
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-09T09:55:47.313Z
Answers.LastActivityDate: 2023-01-09T09:55:47.313Z
Answers.UserDisplayName: Kenneth
Body: <p>Upon upgrading to Craft 4, I've realized that I should implement eager-loading in quite a few places as suggested by the Blitz caching plugin. Most of these are within our page builder, which is built on the NEO field plugin.</p>
  <p>Below is the code for the included <code>page-builder.twig</code>. It's the only relevant code to the question.</p>
  <p>The problem I'm having (if I have indeed understood eager-loading correctly), is that I need to eager-load the field(s) on line 1, but on line 1 I don't yet know which blocks are being loaded, so I can't know which fields to load. It's a chicken-and-egg scenario I think.</p>
  <pre><code>{% set pageBuilderBlocks = entry.pageBuilder.level(1).collect() %}
  {% for block in pageBuilderBlocks %}
      {# Autoload templates from the page-builder-sections folder #}
      {% set blockHandle = craft.firstvet.sectionHandleToTemplatePath(block.type.handle) %}
  
      {# blockHandle becomes the path to file that gets included. #}
      {% include blockHandle ignore missing %}
  {% endfor %}
  </code></pre>
  <p>Each block within the NEO field is represented by a file, which gets included above.</p>
  <p>Is it possible to eager-load in this scenario?</p>
  
Tags: <templating><craft4><eager-loading>
Title: Eager-loading in a page builder built on NEO field
ThreadText: # Eager-loading in a page builder built on NEO field
  
  (Asked by: username_0 on 2023-01-09)
  
  Upon upgrading to Craft 4, I've realized that I should implement eager-loading in quite a few places as suggested by the Blitz caching plugin. Most of these are within our page builder, which is built on the NEO field plugin.
  
  Below is the code for the included `page-builder.twig`. It's the only relevant code to the question.
  
  The problem I'm having (if I have indeed understood eager-loading correctly), is that I need to eager-load the field(s) on line 1, but on line 1 I don't yet know which blocks are being loaded, so I can't know which fields to load. It's a chicken-and-egg scenario I think.
  
  ```
  {% set pageBuilderBlocks = entry.pageBuilder.level(1).collect() %}
  {% for block in pageBuilderBlocks %}
      {# Autoload templates from the page-builder-sections folder #}
      {% set blockHandle = craft.firstvet.sectionHandleToTemplatePath(block.type.handle) %}
  
      {# blockHandle becomes the path to file that gets included. #}
      {% include blockHandle ignore missing %}
  {% endfor %}
  
  ```
  
  Each block within the NEO field is represented by a file, which gets included above.
  
  Is it possible to eager-load in this scenario?
  
  **Tags:** templating, craft4, eager-loading
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-01-09. Score: 1
  
  Im not totally sure about this, but you can just use the 'with' eager loading specifier even if the field does not exist in the blocks created. So imagine the client made a text block, another textblock and some other block it should not give an error if you use with([block:someImageField]).
  
  Again, im not 100% sure if this works correctly
  
  > **Comments:**
  > **username_0**: Well, I would do this, except I'd have to populate each and every query with about 50 fields, which doesn't seem like optimization, quite the opposite...  
  
  ---
  
  