title: JHipster: Filtering entities with criteria - intended Angular client-side approach
body: <p>I've recently started using <a href="http://www.jhipster.tech/" rel="nofollow noreferrer">JHipster</a> - thanks to the maintainers for this fantastic project!</p>
  
  <p>In the current version of JHipster (4.10.2 at the time of writing), entities can have filtering enabled via the entity sub-generator, or by including <code>filter EntityName</code> and <code>service EntityName with serviceClass</code> to the project's JDL file. This produces a Spring project in which the <code>getAllEntities()</code> method in the <code>EntityNameResource</code> class takes a <code>Criteria</code> argument constructed from the URL <code>GET</code> params.</p>
  
  <p>This works out-of-the box with the Swagger UI generated for the endpoint, and the queries issued by this UI demonstrate that the back-end expects each criterion to be in the form of a <code>GET</code> parameter key-value pair; this is consistent with <a href="http://www.jhipster.tech/documentation-archive/v4.10.2/entities-filtering/" rel="nofollow noreferrer">the 4.10.2 Filtering docs</a>.</p>
  
  <p>However, I wonderd whether there is an intended approach to using this from a front-end Angular project that I have missed, beyond making appropriate modifications oneself to construct a conforming URL.</p>
  
  <p>The front-end services use the static function <code>createRequestOption(req)</code> (exported from <code>app/shared/model/request-util.ts</code>) to populate the <code>GET</code> parameters for paging and sorting. This function also expects that the passed-in <code>req</code> object may have a <code>query</code> attribute; initially, I thought that populating this parameter was the intended way to use the back-end filtration.</p>
  
  <p>However, the implementation of <code>createRequestOption(req)</code> currently places the value of <code>req.query</code> into a <code>GET</code> parameter called <code>query</code>; i.e this does not produce the query format expected by the back-end, which expects a separate <code>GET</code> parameter per criterion.</p>
  
  <p>The solution which I have used is to modify <code>createRequestOption(req)</code> to expect an array of key-value pair objects instead of <code>req.query</code> (I've called it <code>req.criteria</code>), and add these to the <code>URLSearchParams</code>'s array (it has to be the array, not the map, since there may be multiple parameters with the same key, e.g. <code>name.in=Megatron&amp;name.in=Optimus</code>).</p>
  
  <p>So I've changed:</p>
  
  <pre><code>params.set('query', req.query);
  </code></pre>
  
  <p>to:</p>
  
  <pre><code>if (req.criteria &amp;&amp; req.criteria.length &gt; 0) {
      req.criteria.forEach((criterion) =&gt; {
          params.append(criterion.key, criterion.value);
      });
  }
  </code></pre>
  
  <p>...with component code populating the array along the lines of the following:</p>
  
  <pre><code>let criteria = [
      {key: 'name.equals', value: 'Optimus'},
      {key: 'power.equals', value: '10'}
  ];
  
  this.entityService.query({
      page: this.page - 1,
      size: this.itemsPerPage,
      sort: this.sort(),
      criteria
  });
  </code></pre>
  
  <p>I just created an example of this working in practice with some form fields filtering a test single-entity monolithic app (currently equals queries only) with this approach in GitLab <a href="https://gitlab.com/ImperfectClone/jhipster-filter-criteria-test" rel="nofollow noreferrer">here</a>.</p>
  
  <p>So, my questions are:</p>
  
  <ul>
  <li>Have I missed the intended way of doing this with the current JHipster version?</li>
  <li>What is the intended use of <code>req.query</code> in the current implementation of <code>request-utils.ts</code>?</li>
  <li>Is this area expected to change in upcoming versions? For example, might front-end search fields be automatically generated in the way in which ElasticSearch-enabled apps do (but for each entity attribute)?</li>
  </ul>
  
  <p>Many thanks.</p>