I’ve also seen a few posts in this community talking about intercooler.js which I’m not a huge fan of because we are already using phoenix channels which I think are better then ajax in our case (maybe?).
I’ve also seen a few mentions of unpoly that I honestly haven’t dug into but seemed complex from the outside.
Ideally I want something that I don’t have to replicate models, validations, have a router ect… in the frontend.
What is everyone else doing for this type of scenario?
I have briefly but from my understanding, and I may be wrong, Drab only helps if you have events on the server that you want to change the frontend with right? Most if not all of my “logic” is on the frontend at least right now.
Ahh I take that back, I just got done reading all of the tutorial section for Drab. That does seem to be something similar to what I’m looking for as well. I’d have to dig into it more to see how well it would work for us.
We’ve been using phoenix channels to open a connect to the backend and we use that to answer the questions on the questionnaires.
Just as a general observation - by choosing to use web sockets (rather than classical request/response) you are pushing towards more client-side rendering which tends to push towards a SPA-style with a client-side framework - not a hard-and-fast rule but there seems to be a tendency.
Our frontend is pretty basic using ES6 and jQuery.
Which suggest to me a general “fiddle with the DOM when new data arrives” type of approach.
What have you be doing in particular? Because maybe all you need is something like a webpack multipage setup. The main benefit would be that you could use (ES2015) modules to “tame” your more complex frontend logic. jQuery distributed via npm should be well enough behaved to be used in a module/bundle environment.
This isn’t a very good reason not to use it. Is this just personal preference or is there a problem you’ve encountered?
SPAs don’t do this. The front-end doesn’t typically validate very much and if you have a websocket connection to the backend to run validation for you theres little need to do so. As for the models, most SPAs just use a plain JSON object, so its just the data that comes from the backend and as long as that contract is not breeched everything is ok. Finally having a different decoupled router is a positive as you’ll want to organize your data access differently than your view layer may want to present it. You don’t want to be locked in to presenting your data in the way that its organized on the back end because that doesn’t always make the most sense to users.
These are opposites. Which is it? Keep in mind, for client logic heavy applications SPAs exist because its a more manageable way to write rich UIs. As mentioned before, the “fiddle with the DOM when new data arrives” type of approach is what leads to a lot of very difficult to find bugs and the reason why frameworks like React have taken off. Your approach can work fine, but it doesn’t scale well in terms of code maintainability.
Yes this is exactly what this approach feels like, which in general is why I’m trying to search for something better. At the very least in the organizational aspect.
I stayed with Brunch for now for the only reason because I didn’t feel like I needed to change it. I’m aware that Phoenix is going to be using Webpack as it’s standard in 1.4 I just haven’t felt the need to switch yet. That being said I haven’t done the research on the pros/cons of both.
But basically I have ES6 modules “mounting” per page and then I can put logic there.
The reason I’m against adding something like these frameworks is I don’t believe we need them right now if ever. It’s not a single page app we just have some complexity on the frontend with some of the UX experience. I’ve worked at several places where in the past a decision was made to build out the applications with these frontend frameworks and from my experience it has always resulted in more work. In general I think the whole single page app design is used more often then it is actually required. I’m not saying that these frameworks are bad but I’m just reiterating the fact that you should use the right tool for the job and from my experience a true SPA is rarely built that warrants these frameworks.
Yea I should clarify or restate what I said here. The “logic” I was talking about is things like hiding show elements, binding to events to submit the data via the websocket, binding to events to delete other elements ect…
The business logic is entirely on the backend, outside of the phoenix web layer.
100% agree with this statement. I think I’m still at a weird spot where I don’t think we need a completely rich SPA experience. I think we have a few basic UX experiences that we want across the site, in the examples I mentioned above. I’m really hesitant to bring in a large frontend framework to do some simple things. I’m looking for more of a general organization to keep things in order as we build out the MVP and understand more about the domain.
If after the MVP we find out that we need a lot more frontend functionality then I think that would be the time to look into some thing else, but even then I feel like personally I’d be hesitant. I just personally haven’t seen these frontend frameworks pay off. That very well may be that I haven’t worked on a team that used them very well, I’m not sure.
I used Backbone.js, and I was happy with my choice. Gives you basic tools, like models, templates, routing and such, but doesn’t enforce you on anything. Have a look.
I don’t know that it’s advisable to start a new project in 2018 with Backbone.js - it’s had its heyday but the world has moved on. jQuery lingers because it makes the DOM-twiddling approach to web page interactivity so easy - but at least with some discipline you should be able to contain it’s impact (it’s just most people don’t bother with that - with predictable results). By adopting a framework - even something as minimal as Backbone.js - the framework gets to call the shots; so at this point it is important that one gets more in return for what is being traded off.
This may not be what exactly you want but I find it works quite well: Phoenix/Absinthe + React/Apollo/TypeScript
You can write GraphQL API with Absinthe, then generate schema from it, then generate TypeScript code (Model definition) and directly consume in TypeScript. It works because both GraphQL and TypeScript are statically typed.
With some command line stuff you can watch this process as you change the API.
Personally, I’m really enjoying Vuejs and highly recommend taking a look at it. You can use small amounts of Vue where you need it, without it taking over everything(SPA land) and without needing npm/webpack etc. I’m currently using it in Rails to provide some nice UI effects with transitions and give structure to the front end JS. I also like using a vue instance as a front end event bus when it’s helpful. I think Vue is a really nice and simple and structured solution to creating a slick front end and gave settler on it for my Phoenix apps in the pipeline. HTH.