Solace Take Home 2: Complete implementation of a page with the Advocates Table

DISCUSSION.md

@@ -0,0 +1,33 @@
+## Future Enhancements
+- **Performance**:
+  - Fetch subset of data
+    - Consider slicing by State? Expose state data to the table, add a dropdown control to select State (ideally preselect this if we know the user's state from lead data or IP geolocation). Fetch more data when state dropdown is changed.
+  - Consider not filtering/highlighting for query length < 2 or 3 characters.
+- **Other polish**:
+  - More advanced query and filter options:
+    - A dropdown to choose whether the query searches all columns (default) or specify a particular column, for instance if you only want to search the Last Name column.
+    - Could support per-column controls:
+      - Make a multi-select dropdown with specialties -- implement filtering to only show advocates that match **ALL** selected specialties.
+        - [Select (Multiple selection variant) - Ant Design](https://ant.design/components/select)
+      - Could also do controls for:
+        - Years of experience (at least 5 years).
+        - Degree type — I did enable this as a column filter with Ant Design's built-in support, but that UI is a little overloaded, IMO. Would be cleaner to pull it out and group with query controls.
+  - For highlighting, support custom query handlers per column:
+    - For phone number: let a pure numeric query like "555456" match the formatted display text like "(555) 456".
+- **Add tests**:
+  - Unit test hooks and utils.
+  - Component tests that check:
+    - Basic render.
+    - Render after entering a query:
+      - Detect that rows are shown/hidden as expected.
+      - Detect correct highlighting.
+    - Reset query.
+- **More**:
+  - Mobile support.
+  - Clean up and centralize definition of design tokens: colors, fonts, etc.
+
+## Some Interesting Parts
+- **Highlighting** was a little tricky working within the Ant Design table and within the (self-imposed) constraint of keeping filterable table generic.
+  - Couldn't use custom renderers defined directly on the columns because they wouldn't have access to the search query.
+  - I could've hoisted the search query up to a context so **AdvocatesTable** could access that, but that would complicate the use of **FilterableTable** and make it less encapsulated.
+  - Instead, I decided to make a custom interface for passing in custom renderers that support highlighting, and then let **FilterableTable** wire them up to get access to the search query. That seemed much better for keeping the boundaries and separation of concerns between components clean.