DEV Community: Simon Bundgaard-Egeberg

Function components in Elixir

Simon Bundgaard-Egeberg — Tue, 04 Jan 2022 09:51:16 +0000

I have been a fan of React for a long time. I like the short, composable syntax of components, and I like that I can extract functionality into small bits and compose my UI of atoms and molecules.

Lately, I have started to find joy in creating apps and web experiences using server-side frameworks. In particular, I have used Blazor, Laravel, Lucky-Framework and Phoenix (elixir).

Of the four, the only thing that could keep my attention for a prolonged period of time was Elixir.

I cannot tell you why.

Great stuff, but what about the components?

What I missed in all the frameworks mentioned above was the single file all included React component.

And now in Phoenix Liveview 0.17 we can do that!

Let's compare React and Elixir.

Elixir

defmodule Layout do
  use Phoenix.LiveComponent

  def header_bar(assigns) do

    reversed = String.reverse(assigns.title)

    ~H"""
      <div>
        <%= reversed =>
      </div>
    """
  end
end

React

const headerBar = (props) => {
  const reversed = props.title.split("").reverse().join("");

  return (
    <div>
      {reversed}
    </div>
  );
}

In a lot of ways, the two are the same. They are terse, self-explanatory and contained. These kind of functions can then be used for creating parts of a larger UI.

In Phoenix liveview, there are things you need to know. Since most of the work is done server-side, there are some things that will be hard to do.
Most noticeably, interacting with the DOM through JavaScript will be difficult.

There are, however, plenty of solutions to this. As an example, below I will show how to create a toggle menu in elixir as a component.

Something to notice here, is that phx-click is an annotation which tells phoenix that this is special. Earlier you would use this when you would send events back to the server to do logic and return data.

In Liveview 0.17, however, we can invoke functions directly from our module. Furthermore, it is assumed that we have created a function component that can render a menu item given some meta data.

The magic here happens in the JS.toggle call in the toggle_menu function. We use a dom selector to target the element with id menu and toggle it. All this is executed locally for the user in the dom.

References:

Phoenix Framework
Phoenix LiveView

Let's scroll to infinity!

Simon Bundgaard-Egeberg — Fri, 24 Sep 2021 09:42:54 +0000

The feed exercise. At this point in time, most apps have some kind of infinite scrollable feed to keep users interested.

The project I will be developing on here is written in Elixir, and uses the Phoenix Framework and liveview to create a webapp.

The why

Jascrafts is a project based knitting app I have created for my wife. When finishing a project, the users (my wife and her friends), can add some data about the project they finished, and optionally add an image. Furthermore, they can choose to share the picture on a feed, that the other users can see.

As the use of the feed grew, it was apparent that I could not just pull out all projects and show them, since that list would be long. And I hate the pages solution where you have to click a next page button.

Therefore: the infinite scroll! Luckily, Elixir is a very pragmatic language, and adding such a feature should not be too difficult.

The behind end

The first query I had looked something like this

defp feed_query() do
    from p in ProjectDetail,
      where: p.is_public == true,
      join: sp in assoc(p, :project),
      order_by: [desc: sp.finished_at],
      preload: [:project]
  end

When rendering this on the front-end, there is nothing more than a simple loop and renders each element as it comes into view.

The basic idea of the back-end pagination is to fetch a pages worth of data, + 1 element.

def feed(%Jascrafts.Feed.Pagination{
        page: page,
        pr_page: pr_page
      }) do
    data = feed_query(page, pr_page) |> Repo.all()
    has_next_page = Enum.count(data) == pr_page + 1

    %{page: Enum.take(data, pr_page), has_next: has_next_page}
  end

  defp feed_query(page, pr_page) do
    from p in ProjectDetail,
      where: p.is_public == true,
      join: sp in assoc(p, :project),
      order_by: [desc: sp.finished_at],
      offset: ^((page - 1) * pr_page),
      limit: ^pr_page + 1,
      preload: [:project]
  end

First, let's take a look on the feed query, this now has an offset and limit. The offset part page -1 * pr_page will make sure we only take out data from a specific point in our database. The limit is set to pr_page + 1.

Let's assume I have a pr_page of 12. If I can fetch > 12 elements out, I know that there is at least one more page of data, even if that next page only has 1 element. If I get <= 12 elements out, I know that I am on the last page.

With that logic we can compose this knowledge in the feed function.

The ahead end

Now this is where it gets sticky. If you don't know, a Phoenix app is server rendered.

Our object here is to listen to front-end events of a page end, and when we are within a specific scroll position, fetch more elements. But I don't want too much of this logic on the front-end.

Liveview hooks is the way to go. To set up a hook, we need a bit of javascript to create the frontend listener.

JavaScript interoperability

let Hooks = {};

let scrollAt = () => {
  let scrollTop = document.documentElement.scrollTop || document.body.scrollTop;
  let scrollHeight =
    document.documentElement.scrollHeight || document.body.scrollHeight;
  let clientHeight = document.documentElement.clientHeight;

  return (scrollTop / (scrollHeight - clientHeight)) * 100;
};

Hooks.InfiniteScroll = {
  page() {
    return this.el.dataset.page;
  },
  mounted() {
    this.pending = this.page();
    window.addEventListener("scroll", (e) => {
      if (this.pending == this.page() && scrollAt() > 90) {
        this.pending = this.page() + 1;
        this.pushEvent("load-more", {});
      }
    });
  },
  updated() {
    this.pending = this.page();
  },
};

Above picture shows the container of my feed in the rendered HTML. Notice the data-page field. This is what glues it together with above JavaScript, and when the scrollAt position hits 90%, it will trigger the load-more and push that event over the liveview web socket connection.

To receive this event on the back-end, we need to implement a handle_event function.

@impl Phoenix.LiveView
def handle_event("load-more", _, %{assigns: assigns} = socket) do
  {:noreply, socket |> assign(page: assigns.page + 1) |> fetch()}
end

defp fetch(%{assigns: %{page: page, pr_page: per, has_next: true}} = socket) do
  %{page: projects, has_next: has_next} = Feed.feed(%Pagination{page: page, pr_page: per})
  assign(socket, projects: projects, has_next: has_next)
end

defp fetch(socket) do
  socket
end

A lot of stuff here, and some of it I will leave to the reader to understand. The important part is that the handle event function triggers on the load-more event that is being sent via the JS snippet we wrote earlier.

Now that we are back in Elixir land, we can do all the smart things we want. In this case, we fetch an additional page of data, and send it back over the LiveView socket connection.

The cool thing about this is that the infinite scroll trigger has nothing to do with data. At this point, for any infinite scrollable list I would be inclined to create, all that I needed to do, was to implement the handle_event("load-more") function, and do the specific use-case stuff there.

Refactor to success!

Simon Bundgaard-Egeberg — Fri, 22 Jan 2021 12:27:16 +0000

Photo by Angelina Yan on Unsplash

Before I get started, the following post is my understanding and how I want to use refactoring, taken from the first 3 chapters of the book "Refactoring" by Martin Fowler.

Get started

I want to note the tech choices that I use in my day to day job. These might not be necessary to understand the post but might shed light on places where my example does not make sense.

React
Jest
Testing-library
Typescript

How I used to do things

Say I get a call to add a feature. This feature intersects with the existing code, so I get on modifying the code to add this new feature.

Say I in my codebase have a number input, and my new feature request is being able to control whether or not the user can input decimals.

My first instinct is to add the function to control it, then wire up the change method to use the new function, and from there add a prop to the components called, let's say withDecimal, and fix the places I need to fix.

During all this, I make sure not to break any existing uses of my number input component.

While there is no apparent fault in this, there might be a long term problem, if this is the end of implementing the feature.

How I do things from there

I have done all the things now, and the new feature is working. Yay.

But at what cost?
Might be free, might not. Just stopping after the feature is implemented, you will never know, or you will learn it the hard way, 2 months down the line, when the number input component is 400 lines long.

From here on out, I want to make sure the features I implement is tested, and then take a good gander at the new feature I just implemented.

In doing this, I will try and see if what I did just solved the issue, and if the solution I made is as clear and pristine as it can be. If not, I refactor the code to be clear, concise, and understandable.

And also, while I'm here, I check if anything else needs tidying up and if it's a small change, I make it.

In the book, this is called the "campsite rule": always try to leave the code a better place than it was in before.

But what to refactor? Good question.
Instead of me telling you how a true master refactoring, our great benefactor has made the first chapter of his book free for all to read. Download it from here.

What?

The only thing I'm doing differently is that after I have implemented a feature, or changed some existing code in my codebase, I make it an exercise to go through the component again to see if I can make it clearer.

A set of rules I used, as learned from the book:

Is there any comments, if so, can I refactor the code to make the comments unnecessary?
If I have long functions, can I refactor parts of them out into separate functions with good names to increase understanding of the "long" functions flow?
Do my filenames match the content of them? Or do it export a NumberInput component from a TextInput file?
Can I extract logic to util files, and reference them from my view files to decrease clutter?

Take note of Foam - a place to manage your notes

Simon Bundgaard-Egeberg — Fri, 18 Sep 2020 07:45:46 +0000

Taking notes and keeping track

The sheer amount of information on the internet is insane. And, just speaking for myself, the amount of information I want to consume also seems enormous.

A lot of great things exist and the only thing keeping me from learning it is knowing its name.

And I think Foam is one of those awesome things.

Foam is a note-taking framework of such. It's part a nice collection of markdown extensions and part something new.

Basically, Foam turns VSCode into a very powerful node linked markdown note-taking power machine.

What I find really cool about this project is that it ditches the regular folder structure, and forces you to link notes by theme and content.

This ends up creating a connected graph of knowledge, where everything about buffer-overflow is linked even though it's written on your notes about C# and Haskell.

From the webpage:
Whether you want to build a Second Brain or a Zettelkasten, write a book, or just get better at long-term learning, Foam can help you organize your thoughts if you follow these simple rules:

Create a single Foam workspace for all your knowledge and research by following the "Getting started" guide.
Write your thoughts in markdown documents (I like to call them Bubbles, but that might be more than a little twee). These documents should be atomic: Put things that belong together into a single document, and limit its content to that single topic.
Use Foam’s shortcuts and autocompletion to link your thoughts together with [[wiki-links]]\ (<-- this is how links look), and navigate between them to explore your knowledge graph.
Get an overview of your Foam workspace using a Graph visualization (⚠️ WIP), and discover relationships between your thoughts with the use of Backlinking.

Foam is like a bathtub: What you get out of it depends on what you put into it.

I use Foam for keeping track of:

What new cool buzzwords I hear,
The status and problems I run into for the different projects I work on,
The different tech blogs and related technologies I write about.

Give it a swirl!

And let me know what you think about Foam, and having a second brain in general. Feel free to comment and ask questions!

Why I think GraphQL is pretty neat, the implementation

Simon Bundgaard-Egeberg — Fri, 10 Jul 2020 12:00:35 +0000

In my last post, I wrote about why I think GraphQL as a concept is pretty neat. This time I will try, through implementation, to show that it is indeed pretty neat.

In my last blog post which you can find here, I teased about what stack I would be using, but just to reclarify, this is it:

Language: Typescript
Server: NexusJS
Frontend-UI: React
Frontend-Network: Apollo-client

Let's go!

I like to write less to do more. I know some might find this as magic, and I tend to agree. Sometimes. When it comes to decreasing the time to market with a product, I think it's good with a little magic.

Using NexusJS can very easily feel like magic. First of all, the actual file that starts the server can be as bare as this:

import { schema } from 'nexus'

schema.objectType({
  name: 'SupremeLeader',
  definition(t) {
    t.id('id')            
  },
})

Notice, how there I nowhere specify my server or what port to listen on.

Nexus will abstract this away and just let me run nexus dev in my terminal, and I will be hitting the ground running!

Now I know that some will say that this is the worst idea ever, but I would have to respectfully disagree. And just to point out, you can, though ENV variables choose which port nexus will use under the hood, and you can also hook into the underlying express server to add your own configuration middleware, should you be so inclined.

My experience with nexus has been: provides sensible defaults, but open for configuration.

Which I happen to think is a good standpoint to take no matter what type of library/framework you are creating.

Anyways, back to the code:

What the above code does for me is to create a single type on my schema. However, at this point, there is no way we can get any data from the server. Therefor, let's implement a query so that we can get some glorious posts from our graph!

schema.extendType({
  type: "Query",
  definition(t) {
    t.field("gloriusLeader", {
      type: "SupremeLeader",
      resolve(parent, args, context) {
          return {
              id: 0
          };
        }
      });
    }
});

Above we create a query to get ourselves a SupremeLeader through the gloriousLeader handle.

How about we see how this query works then?

This query is pretty useless since it's only returning 1, and only an id field, but from here you can grow the schema to whatever size you want. Pretty neat.

Let's see how we use this API to create our SupremeLeader a glorious frontend as well!

schema.extendType({
    type: "Mutation",
    definition(t) {
        t.field("birthNewSupremeLeader", {
            type: "String",
            resolve(parent, args, context) {
                return `All hail our new king`;
            }
        });
    }
});

When manipulating data we call mutations - in essence this is just a name, and not a constraint.

That means that queries essentially can manipulate data. But to make sure that we as developers know if our interactions have side effects on the data, the GraphQL spec splits them up into these two.

The above mutation does nothing but return string indicating success, but whatever logic you would want can be put here.

Just for the fun, let's see how much code we need then to create a GraphQL service that has a SupremeLeader model a query to fetch it, and a mutation to add one.

Okay, some pretty basic files here. The only part that really does something here is the app.ts. That's the file I have been showing snippets of.

So to make a small service that exposes a GraphQL API, with albeit slim to 0 functionality, you really only need 3 files, a app.ts containing the GraphQL code, a package.json file defining the project and its dependencies, and a tsconfig.json file with the typescript setup you need to 'typescript' away.

What you get, however, is an API, documentation (in the form of the types the schema provides), a playground to test your API in, and so much developer happiness that you could just burst.

I hope you liked this post and if you have any questions please let me know in the comments.

Why I think GraphQL is pretty neat

Simon Bundgaard-Egeberg — Fri, 03 Jul 2020 08:34:07 +0000

Time to market is pretty important in this day and age, but sometimes this paradigm is exploited to such a degree that a total rewrite of the entire codebase is necessary for the business to grow larger. And exactly this can, in the end, cost more money than spending a little more time on the product.

It stands to reason that it's a good idea to be on the lookout for tools that can lower the time to market, but keep up high code quality.

I believe GraphQL to be such a tool.

GraphQL is a concept developed to help define the communication between a client, and a set of backend services.

Basically, GraphQL defines a schema, and this schema serves as a contract between the clients and the data/backend layer.

As to not to implement this abstraction yourself, in the examples provided in this post, I will be using a very specific set of tools that I would argue really makes you write less code for more functionality.

GraphQL is a sort of abstraction. It tries to give a way of declaring and structuring a backend service so the service gives a contract that different frontend clients can use.

The structure of a GraphQL query

A sentence that you would undoubtedly have heard if you know about GraphQL is

Ask for what you need, get exactly that

In this example, I have asked my service to find me the user with an id of 1 and return me the name of that user.

Notice how good a GraphQL query reads, when you just go over it line by line.

This means that a frontend developer can, with the GraphQL schema in hand, without endless swagger/openAPI doc surfing develop the features he wants, and get only the data he needs.

Not only is this a win in terms of data sent over the wire, but also in the sense of the developer experience.

But when this is said, GraphQL also provides a whole new way of thinking about resources.

Rest

In the traditional REST-like API's a resource traditionally has a specific path on the API, and the interactions with that resource is a subset of paths extending on the original, example:
get a User: /user/
get a User with id 1: /user/1

This is fine, but as an application grows these endpoints go from 5-10 to 100-1000 different endpoints, which the developer, pretty much without any meaningful help, has to figure out precisely which of those endpoints fits his need.

GraphQL

GraphQL however only specifies a single endpoint: typically /graphql, and from there you do a request for the data you need.

A consequence of having a typed schema means that developers can get help on which resources are available on the schema, and even use the editors IntelliSense capabilities to figure which fields are available on the type.

The power of Zeus, except for autocomplete

There are even tools that live while coding will introspect the backend schema and will, in the editor, show you the fields available, and the types of those fields, and even generate types for the exact queries written.

This reduces the type maintenance there is with having to write and upkeep rest endpoint types.

And let me tell you: the first time that you do and get a list of data available is extremely satisfying.

In two weeks, I will be posting another blog post about how to realize what I have written about here using

Language: Typescript
Server: NexusJS
Frontend-UI: React
Frontend-Network: Apollo-client

Global state management in Svelte

Simon Bundgaard-Egeberg — Thu, 07 May 2020 07:31:37 +0000

Store all the things!

First of all, I would like to advocate what I think is a great strength of Svelte. I will make this short since I assume that everybody who writes a blog about Svelte, explains what it is. If interested look up svelte's homepage
on https://svelte.dev.

I use svelte for a tool to solve simple tasks. Do you need a site to ping microservices and show status for them? Do you need to show
a simple UI consuming an API? Svelte is perfect for these small components. What makes it really great, for me, is that I have all the tools in the Svelte toolbox, but the apps I create are still super lean, and basically cost-free to deploy, since all the things from Svelte I don't opt in to using, do not join my production bundle.

Enough talk, let me try to put my mouth where my money is.

Creating a svelte store is a bit like creating a database for your application.
You can have different types of persistence, you can have readable values, writeable values, and computed/derived values.

These concepts are mirrored in Svelte.

Writeable stores

import { writable } from 'svelte/store';

export const amountOfCoolPoints = writable(0);

Readable stores

import { readable } from 'svelte/store';

export const timeBasedLevel = readable(1, update=>{
   const interval = setInterval(()=>{
      const nVal = Math.floor(Math.random()*10)
      update(nVal)
   }, 1000);

   return ()=>clearInterval(interval);
});

Derived stores

import { derived } from 'svelte/store';

export const timeBasedCoolPoints = derived([timeBasedLevel, amountOfCoolPoints], values=>{
   const [TBLevel, cPoints] = values;
   return TBLevel * cPoints;
})

The test project

These things are relatively simple, but yet incredibly powerful. And one of the most interesting things
is the amount of effort and knowledge you need to commit, in order for you to get up and running with store management.

Creating a globally writeable piece of state is just 1 single line!

The sample project i equally small:

    <script>
        import { amountOfCoolPoints,timeBasedLevel, timeBasedCoolPoints} from './store'


        // Subscription method
        let level;
        timeBasedLevel.subscribe(v=>{level=v})

        // Demo up updating store values with set
        setTimeout(()=>{
            amountOfCoolPoints.set(7)
        }, 2000);
    </script>

    <p>
       time based Level:  {level}
    </p>
    <p>
       cool points:  {$amountOfCoolPoints}
    </p>
    <p>
       time based cool points:  {$timeBasedCoolPoints}
    </p>

Note here that I have used to different ways of getting values displayed in our page, the first one, which is
the 'manual' way, I create a variable, subscribe to the store, and update my local value on updates to the stored value.

This is fine, but also boilerplate, which is not the Svelte way. Therefore the $ syntax is provided.
If used in the template, this will do these things for you, as demonstrated by the cool points and the time based
cool points.

Basically this webpage will start with 0 coolPoints, which then means that we have 0 timeBasedcoolpoints and the timeBasedCoolPoints in derived
by multiplicating timeBasedLevel and amountOfCoolPoints. After 2 seconds though, our coolPoints are updated to 7, and now the numbers
start changing by an interval of 2, as set in the readable store.

Pretty neat.

These stores are global, but usage without proper management can turn a good framework into bad code.
Svelte provides all the tools, but it allows its users to create their own solutions, which is a thing I like.
This does sometimes demand more of the individual developer, especially in large-scale projects, but it's a tradeoff, I would be glad to pay.
And my motto is

There is never a reason to not do it properly

Server-fetched partials

Simon Bundgaard-Egeberg — Tue, 07 Apr 2020 06:41:34 +0000

Laravel is a full-stack server-side rendered framework. And if you want, you can use the Laravel stack to create your whole application from database migrations to the HTML being rendered in the browser.

In my journey to learn Laravel, I have started writing some test apps using the blade syntax built into Laravel. This is in many ways like using a preprocessor for your HTML.

Doing this has allowed me to connect with the HTML roots in a way that was never appealing to do in the React apps I write in my day to day work.

It has even allowed me to see the beauty in server-side rendered pages. And the beauty in trying to optimize them.

In this blog post, I want to try and tackle a basic but very tangible problem.

Imagine that we have a site, where we can view issues, and for these issues create tasks for them.

When browsing a specific issue, I want to allow the user to create a new task, either for that specific issue, or a different one. In the form, I need the server to provide the possible issues to link the task to, and also in which states the task can be in.

Problems?

I want the user to be able to see the page, without the form

Alrighty then, let's crack on.

First of all, I will need a blade partial view and controller action that can return my form.

That looks like this:

// _create_task_partial.blade.php
<form action="/tasks" method="post">

    <x-text-input label="Task title" id="title_id" name="title" type="text">
        <x-slot name="error">
            @error('status', 'issue_id', 'title')
                {{$message}}
            @enderror
        </x-slot>
    </x-text-input>

    @csrf
    <x-select name="status" id="status_id" label="Status">
        @foreach($statuses as $status)
            <option value="{{$status}}">{{$status}}</option>
        @endforeach
    </x-select>
    <x-select name="issue_id" id="issue" label="Issue">
        @foreach($issues as $issue)
            @if($issue->selected)
                <option selected="selected" value="{{$issue->id}}">{{$issue->title}}</option>
            @else
                <option value="{{$issue->id}}">{{$issue->title}}</option>
            @endif
        @endforeach
    </x-select>
    <button type="submit">Submit</button>
</form>

Most of this reads pretty easy, but notice that this view is expecting a variable called $issue and $status, so which ever controller action creates this view, will need to provide these.

Let us see that controller action then!

public function create()
{
  return view('tasks.create', [
    'statuses' => [
      'new', 'started', 'done', 'in_review'
    ],
    'issues' => Issue::all()->map(function ($issue) {
      return (object)[
        'id' => $issue->id,
        'title' => $issue->title,
        'selected' => $issue->id === (int)request('issue')
      ];
    })
  ]);
}

Boy, this is some terse PHP. Let's go through it.
To fetch the issues already present in the database, I am using an Eloquent data model called Issue, and through that I am telling it I want all of them. And of all of those, I want to map them to consist of an id, title and whether or not it should be preselected. For the last check, I am using a helper function called request('issue') which will check the request for either a query param or body with the key of issue. Since this is a get request, it will be the previous case.

And that is most of the work done.

Show us in action now, please!

Let's strip out most of my issue templating, and focus on just fetching the partial.

// issues/show.blade.php

// ... showing all issues

<div id="create-task-form-target">
    <!-- -->
</div>

<script>
  (function fetchTaskCreationForm(){
    fetch('/tasks').then(response=> response.text()).then(html=>{
      document.getElementById('create-task-form-target').innerHTML = html
    })
  })()

</script>

And boom, in comes the form, but only after the initial page load.
This might be an expensive calculation, which took some seconds to finish, no need for our user to wait for that.

And actually, we can take this a step further. How about we cache it?

This way, that IF this page has already been to the page with issues and fetched the form, we cache it for 10 seconds, and if you refresh the page during those 10 seconds, they form will be returned on the initial payload, and not loaded in later. Let's see how:

First of all, our create method, which returns the HTML for the form, should cache the entire HTML payload.

  public function create()
  {

    return Cache::remember('tasks.create', Carbon::parse('10 seconds'), function () {
      return view('tasks.create', [
        'statuses' => [
          'new', 'started', 'done', 'in_review'
        ],
        'issues' => Issue::all()->map(function ($issue) {
          return (object)[
            'id' => $issue->id,
            'title' => $issue->title,
            'selected' => $issue->id === (int)request('issue')
          ];
        })
      ])->render();
    });
  }

Luckily, laravel makes that easy with the Cache interface.

Next, we should have our issues/show.blade.php use this cache if present, otherwise render the data needed for the partial.

    public function show(Issue $issue)
    {
        return view('issues.show', [
            'issue' =>tap($issue)->load('tasks'),
            'form' => Cache::get('tasks.create')
        ]);
    }

Notice that I am adding a key to the view called form, and I am assigning it to the same name as I saved the cache in previously. And it really is that easy.

    @if($form)
      {!!  $form  !!}
    @else

      <div id="create-task-form-target">
        <!-- -->
      </div>

      <script>
        (function fetchTaskCreationForm() {
          fetch('/tasks/create').then(response => response.text()).then(html => {
            document.getElementById('create-task-form-target').innerHTML = html
          })
        })()

      </script>
    @endif

Normally, you would not embed a script tag inside your rendered HTML, but for the sake of this blog, it will do just fine.

A nifty side effect of this, is that if you have any test validating that your view gets the correct data, all of these changes would be reflected in your tests, if using React/Vue as the frontend engine, these things would have to be tested separately.
For instance if I misspelled issue to isue in the template

That's all for now, I hope you enjoyed reading this, and maybe this gave you some inspiration to same fun things to do with Laravel

Soft deletes and pipelines

Simon Bundgaard-Egeberg — Fri, 27 Mar 2020 07:05:52 +0000

Knitzilla is a knitting app that I created for my wife.
Originally it was only supposed to keep track of how many rows she knitted, but in time, it grew.

It is now at a stage where you can commit to several different knitting projects, and you can add and delete counters to each project.

Since I, in time, want my wife to be able to create a portfolio of all the knitting projects that she has finished I needed a system to put this in place.

Luckily for me, Laravel ships just such a feature out of the box.

To make my Project model able to support soft deletes I needed to mutate the user table in my database. This is easily done with a migration.

A quick:

Schema::table('users', function (Blueprint $table) {
  $table->timestamp('deleted_at')
    ->nullable();
});

should fix that right up.

Now with my database updated, the only thing left is to tell my model that I want to use this feature.

Since all my database communication goes through the eloquent model, these things become a breeze.

class Project extends Model
{
  use SoftDeletes;
  // rest of the model

}

Very nice indeed.
However, I need a new way to get all projects now, even the deleted ones. Wouldn't be much of a portfolio if you could never retrieve the actual items.
This is where it becomes a wee bit advanced.

If you have ever written a backend, you surely know what request middleware is, and you properly like it.

What if I told you that such pipelines are not reserved for requests? Laravel provides their abstraction of pipelines, free to use, if you know how to.

I will just show this with a pipeline with a single middleware function, but these can be as large or small as you would like them to be.

First of all, the abstract class we will be working with.

// App/Pipelines/Project/AbstractQueryable

abstract class AbstractQueryable
{
  public function handle($request, \Closure $next)
  {
    if (!request()->has($this->filter_name())) {
      return $next($request);
    }

    $builder = $next($request);
    return $this->apply_filter($builder);
  }

  protected function filter_name()
  {
    return Str::snake(class_basename($this));
  }

  protected abstract function apply_filter($builder);
}

A few things to notice here:

In the filter_name function, I am using a function called class_basename with this context. This is a standard PHP function that extracts the name of the class which it is called with. The cool thing is that it returns the inheritor's name. This means that this function can be implemented in our base class, and reused in all the different filters we want to provide.
- This pattern is depending on a specific naming convention. It expects the filters is the snake case name of the query params from our request.
- This means a class name of Deleted would need to have ?deleted=true in the query params, and BeforeDate would need ?before_date=<some date>
With the last function in the class, we are telling everyone who extends this class that they have to implement an apply_filter function.
In the handle function we decide if this specific piece if middleware needs to activate. If it don't, we just invoke the $next piece of middleware.
If it does, however, we defer the next in the chain to the apply_filter function.

// App/Pipelines/Project/Deleted

class Deleted extends AbstractQueryable
{

  protected function apply_filter($builder)
  {
    return $builder->trashed();
  }
}

With all the smart things already packed away in our AbstractQueryable we only need to add the invoke the necessary function on the query builder.

// App/Project
class Project extends Model
{
  use SoftDeletes;

  public static function allProjectsForUser($id)
  {
    return app(Pipeline::class)
      ->send(Project::query())
      ->through([
        Deleted::class
      ])
      ->thenReturn()
      ->with(["user", "scratchpads", "counters"])
      ->where('user_id', $id)
      ->get();
  }
  // rest of the project model
}

Now it all ties together, we can define a static method on our model and begin the pipeline.
The code here is pretty self-explanatory. We get the Pipeline from our app service container, and through it, we want to send a Project::query() which returns a chainable query much like Entity frameworks fluent query builder.

The thenReturn gives back the query builder and from there was some functionality I want to always be present.

I want all related models to the project, and I am only interested in the project connected to the id the function is invoked with.

Pipelines open up for some pretty neat functionality, and it gives a way to specify a single endpoint, and then have the user, through the pipeline define how the data should be i.e sorted, filtered, paginated and so on.

Maybe it would be nice to have a ?paginate=15&page=1 for the ones who want to paginate, and all, for the ones who want all (i wouldn't know why).

Bonus

If you have read my other laravel posts, you know I like to test it.
So just for the eager learner, I have provided the code I used to test the deleted functionality of the pipeline I created.

class ProjectControllerTest extends TestCase
{
  /** @test */
  public function should_return_deleted_if_present_query_param_present()
  {

    // Assign
    $this->user_under_test->projects()->saveMany(factory(Project::class, 5)->make());
    $first_record = $this->user_under_test->projects()->first();
    $first_record->delete();

    // Act
    $res = $this->getJson("api/projects?deleted=true", $this->headers());

    // Assert
    $res_json = $res->json();
    $this->assertCount(5, $res_json);

  }


  /** @test */
  public function should_return_not_deleted_projects()
  {

    // Assign
    $this->user_under_test->projects()->saveMany(factory(Project::class, 5)->make());
    $first_record = $this->user_under_test->projects()->first();
    $first_record->delete();

    // Act
    $res = $this->getJson("api/projects", $this->headers());

    // Assert
    $res_json = $res->json();
    $this->assertCount(4, $res_json);

  }
}

Develop Laravel with TDD

Simon Bundgaard-Egeberg — Fri, 06 Mar 2020 11:54:14 +0000

Test-driven development helps a developer set up predicates that the code should solve, before writing the actual code.

After the code is written, the test should pass, and the code now supports that predicate.

Sometimes using a purely TDD approach the development time will slow down a lot. And many "buyers" of software solutions do not want to pay this cost upfront.

Laravel provides the tools to create feature tests. These tests fill in the role of integration tests.

Before we get too much into a specific case, it is also worth noting that Laravel gives you an easy way to mock out your database with an in-memory one, which really gives you confidence in the tests you write, since the Feature tests test the data model and its write/read functionality.

The only thing that needs to be added to make sure that you can use this functionality is these lines in the phpunit.xml file.

  <php>
    <server name="DB_CONNECTION" value="sqlite"/>
    <server name="DB_DATABASE" value=":memory:"/>
  </php>

To make sure that each test has its own pristine version of the database to work with, you can add a use statement in the class, which in turn makes sure that the database is wiped between tests.

class ProjectControllerTest extends TestCase
{
  use RefreshDatabase;
  // ....

}

Say for instance we want to make an endpoint that exposes some projects that a user owns. A test for such a feature (before writing the actual controller to expose it) would look something like this:

  /** @test */
  public function can_return_all_user_projects()
  {
    // Assign
    $this->user_under_test->projects()->saveMany(factory(Project::class, 5)->make());

    // Act
    $res = $this->getJson("api/projects", $this->headers());

    // Assert
    $res_json = $res->json();
    $expected_res = $this->user_under_test->projects()->count();
    $this->assertEquals(count($res_json), $expected_res);
  }

This test firstly creates 5 projects to the user under test.
Then it calls the endpoint api/projects which I then expect to return the same amount of projects that I created for the user in the first place.

To start with, this test would fail, since we have no endpoint that returns projects. So let us go ahead and create that.

// ProjectController.php
  public function index()
  {
    $userId = Auth::user()->id;
    $userProjects = Project::where("user_id", $userId)->get();

    return response($userProjects, 200);
  }

First of all, we make sure that we have the authenticated user, and we fetch all of the projects that match the userId from that user.

and boom our test now passes.

Now we get the requirement that all projects can have a scratchpad associated with it.

From here we go back and write a new test that could make sure that if there is a scratch on the project, this scratch is also returned with the project.

such a test might look like this:


  /** @test */
  public function if_present_should_return_scratches_on_get_all()
  {
    // Assign
    $new_project = $this->user_under_test->projects()->save(factory(Project::class)->make());
    $user_details = $this->user_under_test->user_details;

    $new_project->scratchpads()
      ->save(factory(Scratchpad::class)
        ->make(["user_details_id" => $this->user_under_test->user_details->id]));
    // Act
    $res = $this->getJson("api/projects", $this->headers());

    // Assert
    $res_json = $res->json();
    $exptected_res = $user_details->refresh()->scratchpads->toArray();
    $this->assertEquals($res_json[0]["scratchpads"], $exptected_res);
  }

The test above says that if there is a user with a project, and that project has a connected scratchpad, I expect that scratchpad to match the one returned from the endpoint.

Very well, but this test fails at this point, since there is no scratches
present on the payload.
A quick fix to the index function solves this:

  public function index()
  {
    $userId = Auth::user()->id;
    $userProjects = Project::with(["scratchpads"])->where("user_id", $userId)->get();

    return response($userProjects, 200);
  }

And boom, our test is again green.

This was not meant to lecture in the use of TDD, but merely how Laravel provides tools that make this process great and fluent.

As a final note, I want to say that if a feature test has tested anything else than the response from the endpoint, that test should maybe be moved out to a unit test. The Feature tests are meant to test the overall functionality of the feature.

It is specifically for this reason I think that the Laravel feature tests are powerfull. It creates a fine line where there is a lot of value given, for not to much effort.

You can read more about testing in Laravel here (https://laravel.com/docs/7.x/testing)[https://laravel.com/docs/7.x/testing].

Single Page Application API from Laravel

Simon Bundgaard-Egeberg — Thu, 12 Dec 2019 09:02:57 +0000

KnitZilla, the backend(ening);

In my last episode, I wrote about how I got a typescript react app to work in a Laravel stack.

In this episode, I will try to explain why I think Laravel is a cool framework, and why you might want to use it for your next full-stack project!

First of all, let's look at the model.
Laravel provides a Database agnostic tool to write your database migrations in.
For me, being mostly a frontend developer, I wrote my entire database configuration in my first migration, but you might want to do it differently.

What is cool for me, is that I do not need to know the specifics of the underlying database, I just need to maintain a higher-order overview of the model I want in my app.

class CreateUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('projects', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->unsignedBigInteger('user_id');
            $table->foreign('user_id')
                  ->references('id')
                  ->on('users')
                  ->onDelete("cascade");
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('users');
    }
}

And thus, my database is created. I like it! Notice that I am adding a foreign key reference to a user model in this model.

As a developer, after having created the actual persistence model we need to find a way to query our data. Again, Laravel provides an easy to use interface for such options.

class Project extends Model
{
    //
    protected $fillable = [
        "name", "user_id"
    ];
    public function user()
    {
        return $this->belongsTo("App\User");
    }
    public function counters()
    {
        return $this->hasMany("App\Counter");
    }
}

With Eloquent https://laravel.com/docs/6.x/eloquent, we can tell the relations and which fields should be mutable through the model(the $fillable field). And thus, our query system is in place.

USE IT!

How do we then go about using it?
Well in a controller dummy!.

class ProjectController extends Controller
{

    public function __construct()
    {
        $this->middleware('auth:api');
    }

    public function index()
    {
        return response(Project::with("user")
                        ->where("id", Auth::user()->id)
                        ->first());
    }

    public function store(Request $request)
    {
        $userId = Auth::user()->id;
        //
        $name = $request->input("name");
        $project = Project::create([
            "user_id" => $userId,
            "name" => $name
        ]);
        return response($project, 200);
    }
}

First of all, I love how I can add which middleware chain I want to use in the constructor, and it then applies to all routes in this controller.

In the index function, which will be exposed as the get request at the root of this controller will use our eloquent data model.

Since I am using authentication in this controller, I can pull out the id of the user who made the request and then only return the projects associated with that user (In the Project eloquent model I specified a user's function).

Looking closer at the fluent API query I made, the first function chained is called with("user"). This is how you can lazy load values on the request to the database, saving precious roundtrips. The next to parts is pretty self-explanatory.

Later, in the store function (which would map to the POST request of the root) I create a new project resource. And again leveraging that I have the current user through the context, I can safely say that it is this user that I want to add the project on.

This is just the API part of Laravel, and there are so many more cool things that you can do.

To just name a few:

Cron jobs baked in (Task scheduling)
Different middleware groups to different endpoints
Full app expectation tracking
Broadcasting

In summary, using Laravel and React has allowed me, in a very short amount of time, to create a full-stack app, where users can sign up and log in. All endpoints but authentication endpoints are protected, and the data is persisted (in my case in a MySQL database).

Upgrading KnitZilla to a full-stack

Simon Bundgaard-Egeberg — Thu, 28 Nov 2019 09:54:47 +0000

The why

I have previously written a blog post about a knitting app I made for my wife (https://dev.to/itminds/knitzilla-2lj0).

The app was written in reason, and I partially made it to make something useful for my wife, but also to learn something new. And that is indeed the case with KnitZilla V-2!

The new and improved KnitZilla is made with Laravel as a backend, and a typescript React app as my frontend.

Laravel is a very traditional rest framework, providing utilities for middleware, controllers, and routes.

I am mainly a frontend developer, and that sometimes make my choices concerning which backend technologies I use. I like express.js, because it is simple to get started, and simple to define routes. I steer away from more integrated solutions like asp.net core, because I find them more difficult to make sense of right off the bat.

Why Laravel then? I have a web hotel at a place where there is no CLI access.
It does, however, provide a MySQL database as well. Most of my traditional solutions can't be used since I use CLI access to run migrations and start servers.

With that boring stuff out of the way, let us dig into how I did it!?

The how

First of all, scaffolding the laravel app. I mean, that was easy. After running some apt install on my WSL I was ready to use the scaffolder.

composer create-project --prefer-dist laravel/laravel knitzilla

By default, laravel uses blade templates as frontend rendering engine. For this, this does not fly.

By the very least, I need an experience that gives the same feel as the previous one, and that one worked offline. For that reason, I need an SPA with a service worker.

A React.js Frontend

<!-- spa.blade.php -->

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Knitzilla</title>
    <link rel="stylesheet" type="text/css" href="{{ mix('css/app.css') }}">
    <link href="https://fonts.googleapis.com/css?family=Rubik:300,400,500,700,900&display=swap" rel="stylesheet">
    <link rel="manifest" href="/manifest.json" />
</head>

<body>
    <div id="app">
        <app></app>
    </div>

    <script src="{{ mix('js/app.js') }}"></script>
</body>

</html>

Very good, we now know how to serve our new web app. But how do we tell laravel that this is React, and how to parse the typescript files?

By default, Laravel uses webpack to bundle all frontend assets. Laravel also provides an easy API for working with webpack called mix.

// webpack.mix.js
const mix = require("laravel-mix");

mix.react("resources/js/app.ts", "public/js") // tells mix this is a react app
    .sass("resources/sass/app.scss", "public/css") // for whatever global css
    .webpackConfig({ // this config defined the typescript loader
        module: {
            rules: [
                {
                    test: /\.tsx?$/,
                    loader: "ts-loader", 
                    exclude: /node_modules/
                }
            ]
        },
        resolve: {
            extensions: ["*", ".js", ".jsx", ".vue", ".ts", ".tsx"]
        }
    });

Even though it's just a couple of lines here, it's not on by default.

running npm run watch at this point bundles all the react and CSS assets and puts them in the public folder. From here, it is the job of the laravel framework to serve the web app on the correct paths.

Laravel provides different files for initializing different routes. All these different files have a specific middleware chain attached. For instance, you might not want to auth middleware to run on the first request to get the web app.

For this specific scenario, we have our web routes, which will be used to serve our frontend application, and our API routes, which will have API controllers for the data needed in the app.

To register our spa.blade.php file into laravel, we will create a controller and a new route in web.php route config.

<?php
// SpaController.php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class SpaController extends Controller
{
    public function index()
    {
        return view('spa');
    }
}

return view(spa) will look in the blade template folder, and find a file called spa.blade.php and render that. This will serve the file previously shown.

<?php
// web.php
/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/{any}', 'SpaController@index')->where('any', '.*');

Here we specify that on any route from the root, we want to serve the index function from the SpaController file.

El service worker

The last part missing here is setting up the service worker.

I am using workbox from google to handle all my service worker related stuff.

// js/src/service-worker.js
importScripts(
    "https://storage.googleapis.com/workbox-cdn/releases/4.3.1/workbox-sw.js"
);
if (workbox) {
   // service worker related stuff  
}

When the bundling step is done, I will use the workbox CLI to find this template file and create the actual service-worker.js file that will be put in public folder which is statically available to the browser, and from there, it just works.