git-toni / lv-states Goto Github PK

• Allow single values or multi-value
• Think about how to model value ranges

Include:

• How to install
• How to use via macro
• Demo. Show code snippet of the macro.

TODO

• Probably dockerize the demo app.
• Figure out an inexpensive Docker container hosting
• Implement the deployment as part of the pipeline
• Probably have a look at Dockerfile deployment via fly.io https://fly.io/docs/hands-on/start/ (they offer great free tier)

• Evaluate pro's vs con's & document result.
• If compliance with behavior turns out to be preferred, implement so

Export a LVComponent that makes rendering queryable filter easier

• Add documentation to the API

When using any of the lvs helpers, we could make sure the fetcher does exist.

It's currently within its own state key

Features:

• Allows different creation flow statuses
• Happy and bad path modelling (should store errors)

Seems like a useful library on itself even, it could become its own separate hex package as a generic way to LV-render the status of the socket's assigns.

Whenever there is a resource to be fetched asynchronously, it's often useful to have a small set of states to cover that need.

1. data: can either be empty or contain the information to be rendered
2. is_fetching: can be either true or `false.
3. error: is nil or contains a fetching error
4. metadata: contains meta information such as number of records, pagination status, etc.

API

The module allows for each field to be initialized as is_fetching: true/false. By default all fields are initialized as not feching.

The following usage:

use WithFetcheable, [results: :fetching, :shops] 

will build a "fetching" state, ie:

%{
  results: %{
    data: nil,
    is_fetching: true,
    metadata: nil,
   error: nil,
  },
  shops: %{
    data: nil,
    is_fetching: false,
    metadata: nil,
   error: nil,
  }
}

It's up to the Liveview.mount/3 callback to implement the actual fetching.

The number of names sub-states lvs_data, lvs_filters, lvs_search is becoming scattered.

TODO

• Move all sub-states within %Socket{ assigns: %{ lvs: %LvsState{ data, filters, search, ...}}}

TODO

• Arrange the socket viewer in the demo differently so it does not cover the inputs

Export a LVComponent that makes rendering multi-select or single-select easier