Ideas for the evolution of UserFrosting

The dev team has been discussing some changes that we would like to see in future UserFrosting releases.

Some of these are funnelling down into fully backwards compatible updates, like the planned expansions to the bakery CLI tool. However there has also been discussion of features that cannot be introduced in a backwards compatible way, and in extreme cases, will completely change how a particular aspect of UserFrosting is works.

As such I am creating this topic to keep the community in the loop (and to prevent ideas from lost to the RC chat history).

As of posting we have;

  1. Webpack for asset bundling.
    This has been in discussion for awhile now. Its going to be hard to implement, drastically change how the frontend is developed, and if we are going to play to its strengths, require a complete redevelopment of just about every front end component. The stakes are high for this one, but a successful implementation will greatly improve the front end development experience.

  2. A virtual DOM.
    Made popular by Facebook’s React, using a virtual DOM greatly reduces the processing required for scripts to manipulate the webpage. This means code runs faster, and the user has less chances of browser hangs. However JS libraries that have a virtual DOM are in fact a full, deeply intertwined framework, as is the case of React. And in the case of React, even if we got the virtual DOM code out of it, we would be at the mercy of React’s license. As a Facebook product, it understandably does not permit its use in creating a social network. There are however alternatives such as Preact which (presumably) don’t have that same license clause, and lack the full scale framework part, making it very well suited to a PHP backed web app. (Preact also supports JSX language, a clean JS and HTML fusion that would eliminate the need for alternative, and more restrictive templating libraries). Like webpack, this will drastically change things, but isn’t ultimately dependent on it (it would just benefit immensely).

  3. Our own Resource Locator library.
    Currently UF uses RocketTheme’s ‘Toolbox’ library which has a special Universal Resource Locator class. This is the class that allows access to various files via schemes such as assets://path/to/style.css. While an extremely useful tool, it does have some major flaws. A big one is the lack of documentation, another is that the stock interface lacks many of the methods that would benefit the tools various use cases, leaving us with code bloat to handle the shortfalls and ultimately trapped with the library despite the fact is has a reusable interface. There are plans to ditch the RocketTheme implementation as much as possible in the short term (in a BC way), but in the long run we want to remove the dependency entirely.

1 Like

I’d like to expand Sprunje to be a more comprehensive API builder. For example, ideas discussed include:

  • Being able to specify specific columns/eager relationships to load in the request
  • Support for other data sources besides Eloquent/DB
  • Other output formats besides JSON and CSV (perhaps factor that into a separate class)

Alternate data sources is an interesting idea. What kind of data sources are we talking here?

Eh, I’m not really sure. Someone was in chat a few weeks ago, trying to figure out how to get Sprunje to retrieve data from Google BigQuery. There was also talk of Sprunjing an Eloquent Collection. Basically, the idea was to think of Sprunje as more of an API builder, not necessarily tightly coupled to the query-building aspect of it.