DiscipleTools / disciple-tools-theme

Disciple.Tools is a coalition management system for disciple making movements.
https://disciple.tools
GNU General Public License v2.0
40 stars 62 forks source link

Consider(ed) a front end framework? #446

Open grantholle opened 6 years ago

grantholle commented 6 years ago

I'm sure this was part of the discussions early on, but have you considered using a framework such as Vue or Angular? It would clean up the front end code a lot and probably everything else as well as far as templates go...

corsacca commented 6 years ago

Or react? :) The main reason that we didn't is that we want anyone to be able to come in a contribute to the code, or modify it for themselves, without having to learn a new framework at the same time. jQuery is the default way to go with WP. So we just stuck with that.

grantholle commented 6 years ago

Gotcha

grantholle commented 6 years ago

So I want to revisit this... After my experience digging deeper...

I want to advocate to adopt usage of a framework + single page application (SPA). It doesn't matter which framework to me, but I would argue that anyone who is willing to tackle and contribute to a js file that is made up of spaghetti jquery would already understand/take very little time to understand a framework and single file components.

The benefits of organization, reduced ambiguity on how something is done, code cleanliness, reduced bugs, saved time, and many many other things greatly outweigh the arguments against using one, in my opinion. I consider myself pretty experienced, but I struggled understanding what was going on in the js. This is absolutely nothing against who wrote it, this is just the nature of using jquery as a pseudo SPA.

This project has a lot of potential and I personally want to see it being the best it can be, which, to me, would include the adoption and usage of a framework. I would argue that developers could contribute easier than the way it currently is. Frameworks are widely used for really great reasons.

This is a "2.0" change, but one that I think is very necessary if this project wants thrive in a dev community, fully reaching its potential of what it can do and really achieve what it was designed to do.

I would love to get this discussion going again...

corsacca commented 6 years ago

I do agree that a framework would simplify front end dev (and possibly stability and speed). We've put a lot of effort into developing rest endpoints for use in the front end and a possible mobile application. So we are a step in the right direction.

I agree that it would be a 2.0 feature. A full front end overhaul will take time and right now we are focusing on getting main pieces in place.

We will also need to determine which framework and architecture to use.

corsacca commented 6 years ago

Something like this looks interesting: https://github.com/bstavroulakis/vue-wordpress-pwa. Though i have no experience with vue and little with react

grantholle commented 6 years ago

I think the development experience is very similar between the two. It really comes down to someone making the decision.

Mobile apps are a natural progression, for which there's ionic which is really great.

Re: api endpoints, I think that is something that really needs documenting. How a request/response looks would probably be the most important piece of documentation.

ChrisChasm commented 6 years ago

We appreciate you a ton, @grantholle. And we agree. Forking the ui to experiment with a SPA in Wordpress can be done through a child theme. We looked at Angular and have our eyes on Ionic for mobile, and it looks like React is picking up favor in the WP community with Automattic leading the way. When we began the project, the REST api was on the verge of being brought into core for WP, and one of our top goals was stability and staying native in the WP universe ... so that this could be taken by anyone who can install WP and they would not be stuck with anything beyond the recommended requirements of WP. This value of making it solid and stable for the non-techie to grab, upload as a theme, and be off and running is part of the tension leading the dev.

A lot has changed since the beginning of the project, even in our understanding of what the tool needs to be and do. So starting today we would probably do it different.

For better or worse, we have a path for now with the UI. There are big development chunks that seem critical to a successful product that are still missing. For now, the next chunk of months, I think we are going to push forward on the missing chunks and integrations, and table the potential of rewriting the UI.

Again, one of the cool things about the way WP is built, you can child theme DT and begin writing replacement pages for the contact and group archives and single pages, and play with replacing the UI with another framework now, if you felt led to.

One of the reasons we picked WP was to give interested parties the ability to do just that. Fork what we are doing and take it their own direction, or heavily enhance it to their own needs.

Honestly, if you could build a modified SPA through a child theme and it was solid, we would be very interested in moving it into the core DT theme. Again, if we didn't see some other critical features we need to get created first, we would have a lot more juice for this.

@grantholle Thoughts? Your feedback and our hopes of community development like this are the entire reason we are running this open and in a super available environment like WP.

squigglybob commented 3 years ago

Would something like adding vue components to WP be helpful? In summary, it would enable inline vue usage without having to be run through a compiler as WP template part components.

It would give the possibility of starting the process of creating some vue components and being able to manage front end state within those components, before going the whole hog to an SPA later...

grantholle commented 3 years ago

I think that may be helpful, but I believe just going ahead and starting a branch to implement the whole 🐷 would ultimately save more time. I agree that having to have a build step for frontend assets does add complexity.

Another thought would be to have an entirely separate project for the frontend. Can't tell if that version of complexity is better or worse.