The Laravel News site has posted the latest in their "Building a Laravel Translation Package" series of tutorials with a new post focusing on the frontend and getting it connected to the backend functionality.

In the last installment of this series, we talked through the process of manipulating the translations in our application’s language files into a format where we are now in a position to start interacting with them. In this article, we’ll be wiring up the frontend ready to start building out the user interface which will aid users with the process of translation management.

The UI will be developed using the community favorites, Tailwind CSS and Vue.js.

The tutorial starts with the approach for the functionality, taking a more hybrid approach and using a balance of backend and frontend for the majority of the functionality. It then starts in on the technical parts to connect the two halves:

• adding the required routes
• creating the controllers
• building out the views to render the interface

The majority of the post is then dedicated to the creation of the assets - the Javascript and CSS - to create the "framework" the functionality will use to work with the translations.

Armin Weihbold has continued his series looking at building APIs in PHP applications in part two covering the use of the API Platform project as a base. You can find part one here if you need to get caught up.

He picks up right where the last article ends and continues setting up the Docker environment for the application. Once he figured out a small snag in the setup he was able to get the basic documentation (the list of endpoints) up and running.

Next he creates a "material design" administration interface using React showing how he pulled in the requirements he needed to get the interface up and running. Code is included for the interface and a screenshot is included so you can see the end result.

On the Pineco.de site there's a tutorial posted showing you how to implement the Laravel auth system on the frontend re-using the same logic in a single-page Vue.js application as you would on the backend.

If you are using Laravel, probably you are familiar with its ACL. You can easily restrict user’s access by creating policies and binding them to the specific models. It works perfectly on the back-end, but what can we do if our app is something like an SPA?

The post starts with a brief overview of the Laravel ACL handling as it relates to users and policies about what they can do or access. The frontend setup then makes use of a "cheap copy" of the Laravel "gate" handling via a Javascript-based request. They walk you through the preparation work you'll need and the creation of a gate class to define the current policies for CRUD methods. The main "Gate" class is then defined, setting up the before, allow and deny action methods. Finally these pieces are integrated into the Vue.js application with an example of either showing or hiding the "Edit" link based on the user permissions.

On the SitePoint PHP blog they've posted another article from author Christopher Pitt. This time he talks about snapshot testing and if it's a viable way to evaluate code in PHP applications.

Ah-ha moments are beautiful and rare in programming. Every so often, we’re fortunate enough to discover some trick or facet of a system that forever changes how we think of it. For me, that’s what snapshot testing is.

You probably write a lot of PHP code, but today I want to talk about something I learned in JavaScript. We’ll learn about what snapshot testing is and then see how it can help us write better PHP applications.

He starts with a brief introduction to the technology to be used (React in Javascript) and how it could be recreated in PHP. He then covers testing interfaces, evaluating the correct functionality of frontends via various testing tools. He includes some examples of this kind of testing and how it can help a developer mentally break up functionality into components. From there he switches over to the PHP side, introducing the spatie/phpunit-snapshot-assertions package and showing how to use it to check the make up of a snapshot and test several assertions that should exist.

On the Symfony blog they've released an announcement about the release of a tool that wants to help make it easier for Symfony developers to work with frontend resources using the Webpack standard: Webpack Encore.

For everyone that has hit [the barrier of complexity in frontend dependencies and compilation], I'm very excited to show you something we've been working on for the last few months: Webpack Encore.

Encore gives you powerful CSS and JavaScript processing, combination, minification and a lot more, wrapped up in a simple API that's built on an industry-standard tool (Webpack).

He includes an example of the Javascript configuration to build out the Javascript, CSS and dependencies required for his build. He talks briefly about the conformity to the Webpack handling and how Encore fills that role in Symfony applications. The post ends linking to the project repository and the changes required to get the package installed.

The TutsPlus.com site has continued their "Building Your Startup" series with this new article enhancing the application they've already created to send requests for scheduling changes.

As the Meeting Planner alpha testing phase began, the clearest feature gap was the inability to change a meeting after it had been scheduled. It's not an easy problem. Is it okay to just change a meeting without a participant's permission? Or should you ask? Or do either, depending on your role in organizing the meeting? What if you just want to ask if it's okay to meet 15 minutes later—that should be easy, right?

Solving all this required some reflecting on the social aspects of adjusting a meeting. Over time, I realized that the ability to adjust meetings easily after they've been scheduled could make or break the Meeting Planner brand.

He then starts out by describing the "tall mountain to climb" in the number of changes to backend, frontend and UX/UI functionality required to add the feature. He includes all of the code changes and additions that need to be made including:

• migrations to add new tables
• UI updates to add options for rescheduling requests
• form changes
• handling request submissions

Each point on the list includes code, screenshots and anything else that was required to make the update.

The Symfony Finland site has posted a new tutorial showing you how you can share state in a Symfony application between Twig, React and other Javascript-based applications.

Front end development has certainly grown up in the last few years. UI logic is increasingly being moved to the client side, but the traditional server-rendered views aren't going anywhere soon. And they shouldn't.

The two methods will live alongside each other and you'll have to work with two worlds. Let's explore an idea how to make this pleasant to work with, by sharing state between Twig templates and JavaScript.

The post starts with some background on a case where this kind of sharing was a requirement and, while the initial version was scrapped, a prototype application was born. He details what this prototype showcases (which JS libraries) and links to the Javascript involved over on GitHub. They then get into the code examples showing the creation of an AppState object that handles the serializing of the state information and store the result in the database via a Doctrine connection. This value is then output to the pages that require it, making it available to the frontend application (Vue.js, React or plain Javascript).

The TutsPlus.com site has kicked off a new tutorial series today with part one of a look at using the WordPress REST API and AngularJS to create an API-powered frontend application.

In this series about building a WordPress-powered front end with the WP REST API and AngularJS, we will put the knowledge acquired in the introductory series to use. We will learn how we can leverage this knowledge to decouple the conventional theme-admin model supported by WordPress until now. We will plan and build a single-page application (that I've named Quiescent) with a WordPress back end which will feature posts, users, and categories listing pages. We will configure AngularJS routing and build a custom directive and controllers for the resources mentioned above.

In this first part of the series they walk you through some of the planning steps before the application even gets written (including wireframes). From there they get a bare-bones HTML structure setup for the Angular app to live in and make a matching WordPress plugin. This plugin will return a featured image, author name, associated categories and image resize data related to a post. The code for the plugin is included.

On the Symfony Finland site there's a new post with some suggestions on choosing a frontend for your Symfony-based applications according to your needs.

Most projects created with the Symfony framework nowadays also include quite a bit of logic done on the client side. There is a large number of options on the market and this can lead to trouble choosing between the options. The JavaScript scene is full of camps and cutting through the buzz is quite a bit of work. [...] Symfony remains neutral to what is running in the front end of the project. As with most things in web development, there is no single "right" answer to which front end frameworks to use.

They talk briefly about the history of the framework and what kinds of considerations should be made for both the front and backend technology. They also remind you that there's not a "one size fits all" frontend technology out there. They describe a few different kinds of situations (backend heavy, frontend heavy, etc) and make a few suggestions as to which way you might want to go and libraries to investigate.

The next time you're faced with starting work on a front end of a web site or web application built with Symfony, you can reflect on the experience you've got from the back end. There are usually many right answers and no absolute truths.

Chris White has a post to his site sharing a method he's come up with to avoid the burden of file uploads in your PHP application with the help of the offerings of Amazon S3 and some creative coding.

Handling file uploads sucks. Code-wise it's a fairly simple task, the files get sent along with a POST request and are available server-side in the $_FILES super global. Your framework of choice may even have a convenient way of dealing with these files, probably based on Symfony's UploadedFile class. Unfortunately it's not that simple.

[...] For most situations using S3 is a no brainer, but the majority of developers transfer their user's uploads to S3 after they have received them on the server side. This doesn't have to be the case, your user's web browser can send the file directly to an S3 bucket. You don't even have to open the bucket up to the public. Signed upload URLs with an expiry will allow temporary access to upload a single object.

He points out two advantages of this method: that you don't have to handle the upload part of file uploads and that it gives the user more control. He shares a video of the end result (a simple file upload frontend) and the code that you'll need to use the AWS PHP SDK to make it all work together. There's some configuration changes that'll need to be made on the S3 bucket side (like for CORS) but the code itself to make the connection is relatively simple. He does a great job of explaining every step of the way and includes the Javascript needed for the frontend as well.