Conceptual Design - Solid better User Experience

#61

Would it be possible to make web components that do something like this?

<filechooser file-chosen=“the file chosen”>

<fileparser parse-file=“the file chosen” rdf-graph=“the graph chosen”>

<graphdisplayer1 rdf-graph=“the graph chosen”> <!-- d3 force graph -->

<graphdisplayer2 rdf-graph=“the graph chosen”> <!-- bar chart -->

<graphdisplayer3 rdf-graph=“the graph chosen”> <!-- pie chart -->

<grapheditor1 rdf-graph=“the graph chosen”> <!-- simple text editor -->

<grapheditor2 rdf-graph=“the graph chosen”> <!-- editor with fancy autocomplete -->

Where the matching attribute values are mapped to shared properties, and the properties are javascript objects.

Since this is declarative, they would all show at once, and the changes when choosing another file or editing in an editor would be reflected in the other elements.

Then lots of apps could be built with similar html tags, especially if templates for enumerating lists are also possible. @happybeing’s application generator could also be built this way.

#62

Yes it’s for a new version, that :

  • replace deprecated simpleMde editor with easymde
  • allow local install with node/express
  • try to make possible to post in a desired pod, not only on the same one
    …
    I’ll try with solid-local-pod-manager :+1::slightly_smiling_face:
    Thxs for your promptness

does it work on Windows ? as i have some errors

image
image.png2736x1824 414 KB

–> ok it works on localhost:2700, but not on 127.0.0.1:2700

#63

@tag42git it’s totally feasible, and it’s why I love webcomponent, although I don’t like the way they normally share data, with data-binding or other redux tools.

I prefer that they are totally autonomous, so that they talk to each other through the evejs agent system . (@dprat0821)

Each component has a ''named agent" that send data to the agent of another component.

When this agent receive data, he updates the components.

So an app can be build out independent reusable autonomous components as easily as every htmlTag.

Then it would also be easy to replace for example a component by another. If I want my graph to be made with d3js instead of visjs, just import the equivalent component, and use it’s tag & name of communicating agent…

I’d not really know what could be in a piechart component :thinking::crazy_face:, but I will give you a proto of your desired app, with components that exchange those data to each other
Or you can give a try by copying this folder https://github.com/scenaristeur/solidash/tree/master/compagent-spoggy.
It’s all you need to start that type of app ( just duplicate the component/modele-component.js and name it graph-editor ( carefully, dash is necessary) .
In this file change the name at the three place you find model-component or ModelComponent .
Then you can import it in component/component-app.js and use it as a new htmlTag …
Can’t be more simple and it works in the browser, don’t need webpack or other preparation… So could be directly installed on a Pod … :grin:

Edit :
using this components :

  <displayer-chooser name="Chooser"></displayer-chooser>
  <displayer-parser name="Parser"></displayer-parser>
  <displayer-graph name="D3Force" type="d3"></displayer-graph>
  <displayer-graph name="BarChart" type="bar"></displayer-graph>
  <displayer-graph name="PieChart" type="pie"></displayer-graph>
  <editor-component name="Editor" type="simple"></editor-component>
  <editor-component name="Editor" type="fancy"></editor-component>

on this page is an example https://scenaristeur.github.io/solidash/compagent-displayer/

and in the <displayer-chooser> i reuse the <browser-component>, the <tripledoc-profile> & the <explorer-component> that i used in my demo app…

#64

Fantastic! I will give it a try. I don’t have any specific data in mind, I just think making apps should be easy like you are making it possible.

#65

Hi @Smag0,

Can you put more than one displayer-chooser in a document? If so, how do you tell different displayer-graph elements which displayer-chooser they use?

Thanks

#66

Yes , for every component, I use a ‘name’ attribute.
Then I create an HelloAgent with that name. So the chooser ( in fact the tripledoc-profile that is part of the chooser use "this.agent.send(“recipient-agent”, {action: something, data:data) . And in the recipient I use the “receive” prototype to link a function to each type of action. That’s the way I use to make communication between components. Broadcast can also be used as in the login component

#67

Can I do that with just html, not using JavaScript?

#68

Well hum … If the component is well done, no need to write js for the end user.
For example just put a login-comp and a message-comp in a page, the login broadcast when you login and message-comp get the message.
But as a developer of module, you have to define the interface to interact with a component, the inputs & the outputs…

#69

What about putting the interface in the html attributes though? So you could have an attribute like ‘rdf-graph’ with a string value, and that string value would cause a property of that name to be defined for the first component that uses it. Then the next component that uses the same rdf-graph would also have an attribute named ‘rdf-graph’ with the same value as the rdf-graph in the first component and the second component would get a pointer to that property in the first component, and be notified if that property changes. That way the name of the ‘channel’ or interface between the two components would be in the html. The user could choose the channel name and have different channels for the same attribute. The user could put whatever components they wanted on a channel as long they consumed that type of property. Then they could have different sets of components share channels with different names. That way they could have multiple sets of the same kind of components.

If I remember correctly from my polymer period (a couple of years ago), you can do this with data binding, but maybe it could also be done with eventjs.

Just adding to my wish list :grin:

#70

I’m not a fan of Polymer’s data-binding system as explained here, but the idea of ‘channel’ is a way that we could explore, or the concept of groups.

#71

I don’t know Polymer or how other frameworks do this so I’m a bit of a noob but that never stopped me before :wink:…

…so just to mention that the way Svelte binds variables is neat. I don’t understand the full capabilities yet, but you can bind variables to a formula/expression and even a function. So if the inputs change the output is recalculated.

So that might be a way to build components, but specific to Sveltejs

I think I’ve already mentioned Holochain CEPTR, stop just a reminder about that!

#72

It would be useful for displaying different resources side by side, for example a resource and it’s .acl or it’s .meta., or different views or parts of the same resource side by side.

But I agree about polymer’s data binding not being ideal.

Found this which compares data binding code from 9 different frameworks, although it’s a few years old. I don’t know but maybe we need something custom made, but I don’t think it would have to be too fancy.

#73

Web components (made with whatever framework) could share references to things like rdf resources, non rdf resources, web id’s, pods, results from other components, etc., and do it through html attributes with agreed on names, like ‘rdf-resource’ or ‘rdf-graph’ or ‘web-id’, ‘pod’, so no javascript has to be written to make an app. Also new components could be made this way from existing components.

This would be a flexible and simple way to make apps. It only needs agreement on attributes and maybe some kind of simple, generic way of data binding. This library looks like the kind of thing that might be useful.

#74

The level of complexity for Solid apps is higher.

No one individual (or very few) will be able to build really nice, stable, useable enjoyable apps. Not for a while anyway.

Only groups of individuals will be able to do that. Probably corporations.

Unless … some individuals get together and agree on some conventions for components.

Individuals could make nice components.

#75

There is a barrier in terms of learning new things and new ways (federated, social, semantic, client side business logic etc) but I think overall Solid is no more difficult and may even be simpler, because the backend is done for you, simple, standard and once learned won’t change.

The level of difficulty will depend on the nature and complexity of the app, but I don’t see this as an inhibitor because there will be so much scope for simple apps in the short and medium term.

I could elaborate because I’ve thought about this in the context of Solid on SAFE, for a couple of years now.

So I am sure it is not out of the reach of individual developers, or even significantly harder - apart from being like learning a new framework. So a barrier, but not hard to overcome and equally an opportunity to be there first.

#76

I hope you’re right. I don’t mean to be discouraging. I’m just trying to make the case for components :crazy_face: (doesn’t seem to be working)…

But aside from being new, I think the decentralized nature of not only the servers for the data but also the decentralized nature of webids make it more complex than a traditional desktop or client server app.

There is opportunity to do more, for sure.

#77

Thinking about solid component ‘channels’…

They could use the publish/subscribe pattern for the data binding.

Channels might be named or namespaced according to attribute name and maybe also the attribute value. The corresponding property name could be derived from that.

Publishers could also be subscribers as long as they ignore their own publications and don’t publish in response to a subscription.

So for example a web component like:

<a-graph-display-component rdf-resource=“someFileName.ttl”>

would be a subscriber on the rdfResourceSomeFileName channel, but not a publisher unless it had some editing capability.

Then

<a-resource-editor-component rdf-resource=“someFileName.ttl”>

would be both a publisher and subscriber on the same channel.

Subscriber only components would be like read only components and components that publish and subscribe would be like read/write components. Components that are composed of only subscribing components would themselves be only subscribers, but if they’re composed of any publishing components they would be publishers on those channels.

There would be channels for web id’s, profiles, standard things.

Using components to compose apps seems logical to me, but maybe I’m not understanding the big picture.

#78

So for example with custom web components for Solid (in my dreams), the following html could log sideshowtom in to agora’s pod and display someFile.ttl in a force field graph, and also a file browser with someFile.ttl selected

<webId data=“https://sideshowtom.solid.community/profile/card#me” id=“myWebId”>

<pod root=“https://agora.solid.community” webId=“myWebId” id=“agoraPod”>

<channel pod=“agoraPod” data="/public/someFile.ttl" type=“rdf-resource” id=“someFileChannel”>

<a-graph-display data=“someFileChannel” type=“forceField” id=“forceFieldDisplay”>

<a-file-browser data=“someFileChannel” id=“fileBrowser”>

(the webId and pod channels are implicit, and the someFileChannel is explicitly declared. Browsing with the file browser will change the file and the data on the someFileChannel channel so the graph will be updated)

#79

FYI I just learned that sveltejs can output Web Components, so you can build stuff using Svelte components which are really easy to create and use, and then also share them for use with with other frameworks.

I haven’t tried it yet, but have been building some Svelte components to visualise graphs using d3-force which would make a good test.

How to create Web Components Using Sveltejs

It’s trivial using the publish-svelte CLI, or you can set up your build in webpack or rollup etc as explained below.

#80

A channel could maybe take a json array for cross pod channels and multi-edit or upload of files …also maybe resource browser could take a form submitted

<a-web-id data=“https://sideshowtom.solid.community/profile/card#me” id=“myWebId”></a-web-id>

<a-pod root=“https://agora.solid.community” webId=“myWebId” id=“agoraPod”></a-pod>

<a-pod root=“https://someotherpod.solid.community” webId=“myWebId” id=“someOtherPod”></a-pod>

<a-channel data=’[{pod:“agoraPod”, resource: “/public/someFile.ttl”}, {pod:“someOtherPod”, resource: “/public/someOtherFile”}]’ type=“rdf-resource” id=“someFileChannel”></a-channel>

<a-graph-display data=“someFileChannel” type=“forceField” id=“forceFieldDisplay”></a-graph-display>

<a-resource-browser data=“someFileChannel” id=“fileBrowser”>
<a-form>
<textarea rows=“10” cols=“60” name=“data”>
Enter turtle here for rdf resources
</textarea>
<input type=“submit” value=“submit”/>
</a-form>
</a-resource-browser>