Discussion about Lotus::View directions

In all real world RoR projects I have worked or know about the view layer is used to render UI, no one is serving content. Most of them have complex UI screens with a lot of reusable elements that are present not only on different pages, but sometimes on the same page as well. With some of the elements(widgets) having their own JS behavior.

In all of the projects, I see the same problem - following the Rails abstractions just doesn’t work for this complex UIs, there is a lot of view logic in partials, a lot of random partials that are not part of any particular controller, because they are used everywhere, but still people have no idea where to put those. A lot of global space helpers. Some might have moved to the Presenter concept, but they are still issues that most of those elements(widget) require JS to work properly, which is mostly done in very ad-hoc way.

One solution is to move to a complete client side framework to handle the UI part. What is interesting is that every client side framework use composition of objects to represent the UI, while almost every backend framework is stuck to the template abstraction. For me, it’s obvious that the template abstraction is not suitable for UI modeling at all.

I think one of the problems is lack of clear documentation of the limitation of such view system, what types of UI can be modeled, how to do partial AJAX updates, if possible at all, etc. What I see is a lot of inexperienced people grabbing the RoR templates and shooting themselves in the foot with ad-hoc partials and JS. So I think a good explanation of the limitations and possibilities with such system will improve the current situation a lot.

Maybe the future is in client side frameworks with ways to pre-render on the server, I don’t know. But maybe, it is worth considering more object oriented approaches like the Cells gem is trying and define a framework for connecting JS behavior with server side rendering while still keeping the processing logic mostly on the server, written in Ruby.

I think there is a huge lack of clear architectural understanding of the view(UI) layers in the community in general, and even a good documentation on the subject will help tremendously.

I’m starting this discussion to see what Lotus developers think on the subject.

@edzhelyov Hello, you have raised good points.

In my opinion a frameworks should address first most common use cases, and then cover more complex scenarios. All the projects I worked with had the need of render template and partials, only a few could’ve decluttered their code with cells/widgets.

Lotus was built upon the same assumptions.

Technically speaking, which are your needs? Are we talking about to remove the concept of partial in favor of a cell, for those parts of a page that constitute a component? Does this involves direct management of assets such as JS, CSS, images, etc?

Thanks for raising this up.

I have worked many Rails projects and I agree that templates could get cluttered quickly if there is no clear planning on template management from the very beginning. Majority projects start out with simple templates and it is overkilling to go with things like Cell IMHO.

As app grows, the frontend is growing in accordance too and IMHO it should not grow to be worse. Because Rails does not have separate layer for the View (the Controller handles the rendering, and Helpers are half-baked and broken in its own right), users who are loyal to Rails way stubbornly stick everything to helpers and controllers until everything is tangled up.

On the other hand, Lotus has its own View class as a well loved citizen, I would love to to avoid composition architecture like Cell until I am convinced that clear presentation layer does not really solve the problem (feedbacks on commercial apps I will collect).

I’ve worked with 2 e-commerce projects, 1 social site and 1 site builder and the UI there were quite complex. What worries me with all server side frameworks is that there is no notion about UI modeling, so I have to either choose a client side one and use the server as API or go figure how to integrate the server side rendering(and thus the UI composition and state) with the Javascript code.

There are a few things in the client side - UI is a first class citizen, modeled with hierarchy of components, with the idea to pre-render parts of the UI on the server, they win with having one language and one tool that handles UI.

On the server side, I have to figure out this myself. At the moment, Trailblazer, Cells and Apotomo are the most close to what I think is the appropriate approach and I’m researching them.

What worries me with Lotus::View is that I haven’t found any way to re-use UI parts, seems this is implicitly done by using partials. While I prefer to re-use another View objects, instead of having one big View handling a lot of templates.

At the moment I see 3 architectural approaches for the UI on the server:

  1. Provide some kind of simple templates and template re-use, a.k.a Tilt and similar.
  2. Provide something on top of that in form of helpers, presenters, but still rely heavy on templates, ala the Rails way.
  3. Go with the concept of UI components and model the UI with hierarchy of those objects.

Given that we are 2015 and the needs of the projects that I’ve been involved in, I think that for a server side framework the only reasonable options are: 1) and 3), where 2) seems like spending resources on a half-baked solution.

Of course, there is the possibility that with pre-rendered Javascript on the server the whole point to have option 3. might become useless.

I see that Lotus::View is still in early stages, so I wanted to share my thoughts and see where you are heading. I’m still unsure whether that problem should be handled in other languages than Javascript, but given I’m stuck with a big project with a server side requirements I have to figure out how to do that properly.