www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - vibe.d-example illustrating Dynamic Textual Web-Interface

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
Can somebody please show a enlightening example of, so called,

"revamp of the REST interface generator"

added to release 0.7.26 at:

http://vibed.org/blog/posts/vibe-release-0.7.26

I want to use vibe.d to add a modern dynamic web-interface to my 
knowledge graph I'm currently developing.

More specifically I would like an interface that makes rich use 
of dynamic HTML. When the user changes the contents of a 
search/command-line text-field the client logic shall on the fly 
(after a certain delay) lookup related information with 
vibe.d-server and present the user with relevant hits or 
completions in a another part of page (HTML div-block).

Does anybody have a similar vibe.d-project to be inspired from, 
in this regard?
Nov 30 2015
next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 30 November 2015 at 10:08:17 UTC, Nordlöw wrote:

 Can somebody please show a enlightening example of, so called,

 "revamp of the REST interface generator"

 added to release 0.7.26 at:

 http://vibed.org/blog/posts/vibe-release-0.7.26

 I want to use vibe.d to add a modern dynamic web-interface to 
 my knowledge graph I'm currently developing.

 More specifically I would like an interface that makes rich use 
 of dynamic HTML. When the user changes the contents of a 
 search/command-line text-field the client logic shall on the 
 fly (after a certain delay) lookup related information with 
 vibe.d-server and present the user with relevant hits or 
 completions in a another part of page (HTML div-block).

 Does anybody have a similar vibe.d-project to be inspired from, 
 in this regard?


I have written a mpd (Music Player Daemon) client in D and just 
finished the web app (bar a couple of features).

All of the rendering is done on the client and only json data is 
transmitted between server and web app. Just finished the 
WebSocket part so if anybody changes the music/volume/playlist, 
all clients update the interface.

The code could use a cleanup/refactoring but everything is 
working.

The D parts of interest are the MpdApiInterface1 and MpdApi1 
classes in source/app.d

For the JS parts you can start with source/index.js, but its full 
of ES6 classes and react code. So that might not be your cup of 
tea. In index.js there are mainly React Classes (basically html 
renderers) and React Container Classes (basically code handling 
input changes).

In the source/actions folder there are some js files that call 
the server and modify state (volume/song). In the source/stores 
folder, some js files that only retrieve data.

The js architecture if influenced by react/flux/facebook's, but I 
am toying with it to see what fits for me. Specifically I rely a 
lot on RxJS for the observables.

For the project I decided to put js and d files in the same 
folders. That might not have been a good idea. Also dub has some 
issues with one of the D dependencies that I haven't updated in 
months.

Code can be found here: https://bitbucket.org/skoppe/mpc/src
Nov 30 2015
parent reply David DeWitt <dkdewitt gmail.com> writes:
On Monday, 30 November 2015 at 20:05:42 UTC, Sebastiaan Koppe 
wrote:


 Code can be found here: https://bitbucket.org/skoppe/mpc/src


Looks good.  Have you looked at Redux and Webpack?  I am working 
on a Redux example and we have switched to Webpack and Redux at 
work and it is nice.
Nov 30 2015
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 30 November 2015 at 20:23:48 UTC, David DeWitt wrote:

 Have you looked at Redux and Webpack?  I am working on a Redux 
 example and we have switched to Webpack and Redux at work and 
 it is nice.


I know about both yes. Webpack would probably beat browserify, 
but I haven't gotten the time to migrate myself. Their hot code 
reloading looks good though.

Isn't redux the client side for GraphQL? I followed it a bit but 
it being so fresh, decided to wait.

A GraphQL interface generator for vibe.d would be nice.
Nov 30 2015
parent David DeWitt <dkdewitt gmail.com> writes:
On Monday, 30 November 2015 at 20:38:12 UTC, Sebastiaan Koppe 
wrote:

 On Monday, 30 November 2015 at 20:23:48 UTC, David DeWitt wrote:

 Have you looked at Redux and Webpack?  I am working on a Redux 
 example and we have switched to Webpack and Redux at work and 
 it is nice.


 I know about both yes. Webpack would probably beat browserify, 
 but I haven't gotten the time to migrate myself. Their hot code 
 reloading looks good though.

 Isn't redux the client side for GraphQL? I followed it a bit 
 but it being so fresh, decided to wait.

 A GraphQL interface generator for vibe.d would be nice.


Redux is luscious!!!  It is a flux-like implementation but you 
dont have to deal with individual stores as the app's state lives 
in a single object tree. Once you go thru it you'll like it.


https://github.com/rackt/redux

https://github.com/xgrommx/awesome-redux
Nov 30 2015
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 30.11.2015 um 11:08 schrieb Nordlöw:

 Can somebody please show a enlightening example of, so called,

 "revamp of the REST interface generator"

 added to release 0.7.26 at:

 http://vibed.org/blog/posts/vibe-release-0.7.26

 I want to use vibe.d to add a modern dynamic web-interface to my
 knowledge graph I'm currently developing.

 More specifically I would like an interface that makes rich use of
 dynamic HTML. When the user changes the contents of a
 search/command-line text-field the client logic shall on the fly (after
 a certain delay) lookup related information with vibe.d-server and
 present the user with relevant hits or completions in a another part of
 page (HTML div-block).

 Does anybody have a similar vibe.d-project to be inspired from, in this
 regard?


This would be more targeted to the web interface generator 
(vibe.web.web), which is not affected by the changes mentioned above, 
but the interface is pretty similar. For a very simple example, you can 
have a look at this:
https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web_ajax
Nov 30 2015
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 1 December 2015 at 07:04:25 UTC, Sönke Ludwig wrote:

 Am 30.11.2015 um 11:08 schrieb Nordlöw:

 Does anybody have a similar vibe.d-project to be inspired 
 from, in this
 regard?


 This would be more targeted to the web interface generator 
 (vibe.web.web), which is not affected by the changes mentioned 
 above, but the interface is pretty similar. For a very simple 
 example, you can have a look at this:
 https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web_ajax


I have seen a lot of sites using this approach. I feel that once 
complexity increases (more dynamics, popups, real-time 
validation, spa) it runs into some maintenance issues.

Let me elaborate. In the beginning all html is generated on the 
server. Then more features are added and slowly more html is 
generated/manipulated in the client. Now you have this 
split-brain were html is generated both on the server and the 
client, but both in different languages, with different template 
engines. To put it simply, it doesn't scale well.

The solution would be to shift the generation of html to the 
client (for example see trello, digital ocean, etc.). The only 
issue there is that the first page load takes longer. This can be 
solved by rendering the first page on the server. With nodeJS 
this is easy since you can reuse the same code, with D this is a 
little harder.
Dec 01 2015