@genesislcap/expression-builder 14.248.0

package/FUTURE.md

@@ -0,0 +1,164 @@
+I discussed with an AI about how we can improve the implementation to be more efficient in future
+
+=======user 3========
+
+Great, I will build this implementaiton. This should suit me for now. However I have a question about a future improvement, just to see whether this solution can be improved in future or whether it would block it off. Is there a way to assign IDs in a cleverer way to make searching for parts of the state to update quicker to be more efficient? This probably isn't necessary unless the user creates a huge nested expression, but it's still good for me to know about this
+
+=======response========
+Okay, that's a great question. While the simple incremental ID approach works well, there are strategies for potentially optimizing the state update process, especially for very large, deeply nested query builders. These strategies involve creating more structured or hierarchical IDs that make searching more efficient. However, keep in mind that the added complexity may not be worth it unless you actually encounter performance issues with large expressions.
+
+Here are a few ideas:
+
+**1. Hierarchical IDs (Path-Based IDs)**
+
+   *   **Concept:** Embed the path from the root to the node within the ID itself. This allows you to quickly locate the node without traversing the entire tree.
+
+   *   **Implementation:**
+
+    *   When creating a new group or rule, construct its ID by concatenating the IDs of its ancestors, separated by a delimiter (e.g., "/").
+
+    ```typescript
+    // Example (assuming Group and Rule now have a parentId property)
+
+    generateRuleId(parentId: string | null): string {
+      return `${parentId ? parentId + '/' : ''}rule-${this.nextRuleId++}`;
+    }
+
+    generateGroupId(parentId: string | null): string {
+      return `${parentId ? parentId + '/' : ''}group-${this.nextGroupId++}`;
+    }
+    ```
+
+    *   To update a node, you can split the hierarchical ID to traverse down the tree:
+
+    ```typescript
+    function updateValue(model: Group, path: string, newValue: any) {
+      const ids = path.split('/');
+      let current: any = model;
+
+      for (let i = 0; i < ids.length - 1; i++) {
+        const id = ids[i];
+        current = current.rules.find(r => ('groupId' in r && r.groupId === id) || ('ruleId' in r && r.ruleId === id)); //Union type issues
+        if (!current) return; // Path doesn't exist
+      }
+
+      const lastId = ids[ids.length - 1];
+      const target = current.rules.find(r => ('groupId' in r && r.groupId === lastId) || ('ruleId' in r && r.ruleId === lastId));
+
+      if (target) {
+        target.value = newValue; // Or, make an immutable update here
+      }
+    }
+    ```
+
+   *   **Benefits:**
+
+    *   **Faster Lookups:** You can traverse directly to the node instead of searching the entire tree.
+    *   **Clear Node Context:** The ID provides immediate information about the node's position in the hierarchy.
+
+   *   **Cons:**
+
+    *   **Longer IDs:** Hierarchical IDs can become quite long in deeply nested expressions.
+    *   **More Complex ID Parsing:** Extracting information from the ID requires parsing the path.
+    *   **Immutability Challenges:** Path based mutations can be tricky as the ID is essential for finding the target object
+
+   *   **Use Cases:** This approach is most beneficial when you perform frequent updates to specific nodes and when the depth of nesting can be significant.
+
+**2. Indexes and Maps**
+
+   *   **Concept:** Maintain separate data structures (maps/dictionaries) that index nodes by their IDs. This provides O(1) lookup by ID.
+
+   *   **Implementation:**
+
+    1.  **Node Map:**
+
+        ```typescript
+        // expression-builder.ts
+        @observable nodeMap: {[id:string]: Rule | Group} = {}; // Or Map<string, Rule | Group>
+        ```
+
+    2.  **Update Node Map:** When creating or deleting a node, update the `nodeMap`.
+
+        ```typescript
+        // When creating a rule:
+        const ruleId = this.generateRuleId();
+        const newRule: Rule = {
+          config: this.config,
+          ruleId: ruleId
+        };
+        this.nodeMap = {...this.nodeMap, [ruleId]: newRule}
+
+        //When deleting a rule
+         delete this.nodeMap[ruleId];
+         this.nodeMap = {...this.nodeMap}
+        ```
+
+    3.  **Lookup:** To update a node, simply access it directly via its ID:
+
+        ```typescript
+        const rule = this.nodeMap[ruleId];
+        if (rule) {
+          // Update the rule
+        }
+        ```
+
+   *   **Benefits:**
+
+    *   **Extremely Fast Lookups:** O(1) time complexity for finding nodes by ID.
+
+   *   **Cons:**
+
+    *   **Memory Overhead:** Maintaining the index adds memory overhead.
+    *   **Synchronization:** You need to ensure the index is kept perfectly synchronized with the main data structure. Every time the tree changes, the index must be updated.
+    *   **Additional Maintenance:** Requires careful management to avoid inconsistencies.
+
+   *   **Use Cases:** This approach is valuable when you need the absolute fastest lookup times and are willing to trade off memory and added complexity.
+
+**3. Structural Sharing and Immutability Helpers**
+
+   *   **Concept:** Tools like Immer and Mori.js can help you perform immutable updates to deeply nested data structures more efficiently. They use structural sharing to minimize copying, so only the parts of the data structure that are actually modified are recreated.
+
+   *   **Implementation:** Use Immer's `produce` function to create immutable updates:
+
+    ```typescript
+    import { produce } from 'immer';
+
+    handleFilterSelected(event: CustomEvent) {
+      const { ruleId, filterId } = event.detail;
+
+      this.model = produce(this.model, draft => {
+        //locate your object here
+        //draft is the mutable copy you can directly manipulate
+      });
+    }
+    ```
+
+   *   **Benefits:**
+
+    *   **Simplified Immutable Updates:** Immer handles the complexities of immutable updates, making your code cleaner.
+    *   **Performance Optimizations:** Structural sharing reduces copying, improving performance, especially for large data structures.
+
+   *   **Cons:**
+
+    *   **Library Dependency:** Introduces an external dependency.
+    *   **Learning Curve:** Requires understanding how Immer works.
+
+   *   **Use Cases:** This is a good general-purpose optimization technique for any application with immutable state management.
+
+**Which Approach to Choose?**
+
+1.  **Start Simple:** Implement the basic incremental ID approach.
+2.  **Profile:** If you notice performance issues with large expressions, use your browser's developer tools to profile the update process and identify bottlenecks.
+3.  **Optimize Strategically:**
+    *   If lookups are slow, consider a `nodeMap` (remembering to carefully manage synchronization).
+    *   Use Immer to simplify immutable updates and potentially improve performance through structural sharing.
+    *   Hierarchical IDs are more complex and should only be considered if the other techniques aren't sufficient.
+
+**Important Considerations**
+
+*   **Premature Optimization:** Don't over-optimize prematurely. Focus on creating a working solution first, and then address performance issues if and when they arise.
+*   **Test Thoroughly:** Any time you introduce optimizations, test your code thoroughly to ensure that the optimizations don't introduce bugs.
+*   **Trade-offs:** Be aware of the trade-offs between performance, memory usage, and code complexity.
+
+By following this iterative approach, you can build a query builder that is both functional and performant.
+

package/README.md

@@ -0,0 +1,3 @@
+# Genesis Foundation Expressions
+
+TODO

package/custom-elements-manifest.config.js

@@ -0,0 +1,14 @@
+module.exports = {
+  /** Globs to analyze */
+  globs: ['src/**/*.ts'],
+  /** Directory to output CEM to */
+  outdir: './dist',
+  /** Run in dev mode, provides extra logging */
+  dev: false,
+  /** Enable special handling for FastElement */
+  fast: true,
+  /** Include third party custom elements manifests */
+  dependencies: true,
+  /** Output CEM path to `package.json`, defaults to true */
+  packagejson: true,
+};