search

assemblee-virtuelle / semapps

A toolbox to create semantic web applications
https://semapps.org
Apache License 2.0
88 stars 9 forks source link

Extract frontend components in a separate library #1256

Open srosset81 opened 6 months ago

srosset81 commented 6 months ago

Once the data provider and auth provider will support "regular" Solid servers, the frontend components will be usable by any Solid developers.

I think it's the good time to split the backend services and frontend components from SemApps, which cause confusion, since it make people believe that the two need to be used together.

So I propose to keep "SemApps" as the name for backend services, to find a new name for frontend components and to move the frontend documentation to a new Starlight-based website.

What name shall we use ?

Ideas:

Ping @simonLouvet @fluidlog @VincentFarcy @GuillaumeAV (we are requesting funds from NLnet for this issue, amongst others)

Related issues

srosset81 commented 6 months ago

Found out that the following domains are available for around 10€ a year:

ldf domain names are generally not available, or cost more than 150€ a year. The https://ldf.js.org domain is also taken by a project that is not updated since 2019.

GuillaumeAV commented 6 months ago

If you receive funds I want to be paid for my contribution on the brainstorming for the name !

SemApps could be used for the frontend component no? And we could have SemBack for the backend ?

We also had Linked data management system ..

Le mer. 22 mai 2024, 15:34, Sébastien Rosset @.***> a écrit :

Once the data provider and auth provider will support "regular" Solid servers https://github.com/assemblee-virtuelle/semapps/issues/1121, the frontend components will be usable by any Solid developers.

I think it's the good time to split the backend services and frontend components from SemApps, which cause confusion, since it make people believe that the two need to be used together.

So I propose to keep "SemApps" as the name for backend services, to find a new name for frontend components and to move the frontend documentation https://semapps.org/docs/frontend to a new Starlight https://starlight.astro.build/fr/-based website.

What name shall we use ?

Ideas:

Ping @simonLouvet https://github.com/simonLouvet @fluidlog https://github.com/fluidlog @VincentFarcy https://github.com/VincentFarcy @GuillaumeAV https://github.com/GuillaumeAV (we are requesting funds from NLnet for this issue, amongst others)

— Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/1256, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABO75HAM7OAWPKIJHBHC4HTZDSNE7AVCNFSM6AAAAABIDVKQ6OVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTANJVHAYDCMA . You are receiving this because you were mentioned.Message ID: @.***>

srosset81 commented 6 months ago

If you receive funds I want to be paid for my contribution on the brainstorming for the name !

Your contribution is priceless ! ;-)

SemApps could be used for the frontend component no?

I find the name SemApps to be confusing, as we don't know what "apps" we are talking about. Also "semantic" is less and less used, except in academic fields.

simonLouvet commented 5 months ago

key words

I try to put them together

srosset81 commented 2 weeks ago

Following the discussion on the 22th of October with @nikoPLP and @Laurin-W, I came up with this idea:

The framework should be framework-agnostic, with several layers.

flowchart TD
    A(Core functions) --> B(React components and hooks)
    A --> C(VueJS components)
    A --> D(Svelte components)
    B --> E(React-Admin data provider)
    B --> F(Refine data provider)

The core functions would include basic data fetching stuff such as getOne, getList, etc. But also real-time subscriptions (via Solid notifications or NextGraph pub/sub) and containers detection (via VOID, TypeIndex or SAI)

The React layer could include components and hooks that can be used without React-Admin. This is where we would put the current ActivityPub hooks (useCollections, useInbox...).

The React-Admin layer would include a React-Admin-compatible data provider. If it is used, then we can use all the React-Admin hooks (such as useGetOne) as well as the large amount of components. But we will not be able to use live updates, since this is a paid feature of React-Admin.

A Refine data provider would probably not be a lot of work, and would open to another community of developers (there are as many stars on GitHub for Refine than for React-Admin). Plus Refine provide tools for live updates, without needing to pay more.

nikoPLP commented 2 weeks ago

Sounds very good!

And in NextGraph implementation of those core functions (for those who want to use directly nextgraph APIs) will not be based on solid notifications but on nextgraph system of pub/sub.

We share work on those core functions definition together.

Also I am planning to add another "derivation" of those core functions into the react store system for nodeJS/Deno called Valtio, for developers who want to do some services based on our "unified framework"