# Customisation hooks

!!! abstract “”

    How `scinexus` uses module-level registry functions to let downstream packages customise summary display and identifier extraction without subclassing.

## The pattern

`scinexus` uses module-level registry functions to let downstream packages customise behaviour without subclassing or monkey-patching. Each hook follows the same shape:

- `set_*(func)` registers a callable (or `None` to clear)
- `get_*()` returns the currently registered callable (or the default)

This keeps `scinexus` free of dependencies on downstream packages while still allowing them to integrate deeply.

## `set_summary_display` — transforming summary output

Data store summary properties (`.describe`, `.summary_logs`, `.summary_not_completed`, `.summary_citations`, `.validate()`) collect their data as plain Python dicts or lists of dicts. By default these are returned as-is.

A downstream package can register a display function that transforms these raw structures into richer objects. The function must accept `(data, *, name)` where `data` is the raw dict or list and `name` is the summary method name (e.g. `"describe"`).

### How `cogent3` uses this

When `cogent3.app` is imported, it registers a function that converts summaries into `cogent3.core.table.Table` objects:

```python { notest } from scinexus.data_store import set_summary_display from cogent3.core.table import Table

def _summary_to_table(data, *, name): if isinstance(data, dict): title = data.pop(“title”, name) rows = [[k, v] for k, v in data.items()] return Table( header=[“Condition”, “Value”], data=rows, title=title, )

    if isinstance(data, list):
        if not data:
            return Table(header=[], data=[], title=name)
        header = list(data[0].keys())
        rows = [list(row.values()) for row in data]
        return Table(header=header, data=rows, title=name)

    return data

set_summary_display(_summary_to_table)

    After this registration, every call to `dstore.describe` or `dstore.summary_not_completed` returns a `Table` with a rich notebook repr, rather than a plain dict.

    ## `set_id_from_source` — customising unique ID extraction

    When `apply_to()` or `as_completed()` processes a data store, each result needs a unique identifier so the writer can store it and skip already-processed inputs on subsequent runs. By default, `scinexus` extracts this ID using `get_unique_id`, which strips format suffixes from file names:

“gene_001.fasta.gz” → “gene_001”

    If your data uses a different naming convention — for example, IDs embedded in the file content or in a metadata field — you can register a custom extractor:

    ```python { notest }
    from scinexus.data_store import set_id_from_source

    def my_id_extractor(data):
        """Extract ID from a metadata dict."""
        return data.info.source.split("/")[-1].split("_")[0]

    set_id_from_source(my_id_extractor)

The registered function is consulted by:

- `WriterApp.apply_to()` — to derive output record keys
- `AppBase.as_completed()` — to identify results
- `NotCompleted` — to normalise the `source=` attribute on error records

Pass `None` to restore the default:

`python { notest } set_id_from_source(None) # back to get_unique_id`

Per-call overrides via the `id_from_source` keyword on `apply_to()` and `as_completed()` still take precedence over the registered function.

## The default ID pipeline: `get_data_source` → `get_unique_id`

The default extractor, `get_unique_id`, works in two steps:

1. `get_data_source(data)` extracts a source string from the input. This is a singledispatch function that handles:
   - `str` / `Path` → the file name
   - `dict` → looks for `data["info"]["source"]` or `data["source"]`
   - `DataMemberABC` → the member’s `unique_id`
   - Any object with a `.source` attribute → recurses on that attribute
2. `get_unique_id(name)` strips format suffixes (e.g. `.fasta`, `.gz`) from the source string returned by `get_data_source`.

Together they turn inputs like `DataMember(unique_id="gene_001.fasta.gz")` into the key `"gene_001"`.