PoshVine

poshvine

If you're searching for a simple and effective method to incorporate real-time page views into your Next.js website, you've come across the perfect tutorial on this topic. In this article, I will guide you through the process of integrating real-time page views into your Next.js website using Turso and Drizzle ORM. Turso: A Game-Changing SQLite Edge Database Let me introduce you to , the groundbreaking SQLite edge database that will revolutionize your website. Turso is built on the robust libSQL framework and offers an astonishing free plan that lasts indefinitely. With this plan, you'll enjoy a generous 8 GB of total storage and the ability to create up to 3 databases across 3 different locations. Prepare to have your expectations completely exceeded! Turso Drizzle ORM: The Cutting-Edge Object-Relational Mapping Library is an advanced object-relational mapping library designed specifically for Node.js and TypeScript applications. This powerhouse provides comprehensive support for multiple databases, migrations, and query building. It's like having a turbocharged engine powering your website! Drizzle ORM Setup Turso database Install the Turso CLI (For more options ): Click here brew install chiselstrike/tap/turso Sign up to Turso: turso auth signup Create a new database turso db create [db-name] Get the URL of your database (Starts with ): libsql:// turso db show [db-name] Access your database shell: turso db shell [db-name] Create a new table for : views CREATE TABLE IF NOT EXISTS views (
    slug TEXT PRIMARY KEY,
    title TEXT,
    count INTEGER
); Create an token auth turso db tokens create [db-name] -e none Now inside file, add the following: .env DATABASE_URL=libsql://[db-url]
DATABASE_AUTH_TOKEN=[auth-token] Connect Next.js to Turso In order to connect our site to the database, we need to use Drizzle ORM. All we have to do is install couple of packages and set them up. Install Drizzle ORM and libSQL client: npm i drizzle-orm @libsql/client Create a file to initialize your Turso client lib/turso.ts import { createClient } from '@libsql/client'
import { drizzle } from 'drizzle-orm/libsql'
import { integer, sqliteTable, text } from 'drizzle-orm/sqlite-core'

const connection = createClient({
	url: process.env.DATABASE_URL || '',
	authToken: process.env.DATABASE_AUTH_TOKEN,
})

export const db = drizzle(connection)

export const viewsTable = sqliteTable('views', {
	slug: text('slug').primaryKey(),
	count: integer('count').notNull().default(0),
}) Now we create and use it to increment and fetch page views app/api/views/[slug]/route.ts import { eq } from 'drizzle-orm'
import { type NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'

import { db, viewsTable } from '@/lib/turso'

interface Options {
	params: {
		slug: string
	}
}

export const GET = async (request: NextRequest, { params }: Options) => {
	const slug = z.string().parse(params.slug)

	const data = await db.select().from(viewsTable).where(eq(viewsTable.slug, slug)).all()

	const count = !data.length ? 0 : Number(data[0].count)

	return NextResponse.json({ count })
}

export const POST = async (request: NextRequest, { params }: Options) => {
	const slug = params.slug

	const data = await db.select().from(viewsTable).where(eq(viewsTable.slug, slug)).all()

	const count = !data.length ? 0 : Number(data[0].count)

	await db
    .insert(viewsTable)
    .values({
      slug,
      count: 1,
    })
    .onConflictDoUpdate({
      target: viewsTable.slug,
      set: {
        count: count + 1,
      },
    })
    .returning()
    .get()

	return NextResponse.json({ count: count + 1 })
} Finally, we create component to display the page views which we can use in our blog posts ViewCounter.tsx 'use client'

import { useEffect } from 'react'
import useSWR from 'swr'

import fetcher from '@/lib/fetcher'
import { PostView } from '@/lib/types'

export default function ViewsCounter({ slug, trackView }: { slug: string; trackView: boolean }) {
	const { data } = useSWR<PostView>(`/api/views/${slug}`, fetcher)
	const views = new Number(data?.count || 0)

	useEffect(() => {
		const registerView = () => {
			fetch(`/api/views/${slug}`, {
				method: 'POST',
			})
		}

		if (trackView) {
			registerView()
		}
	}, [slug])

	return (
		<p className="font-mono text-sm tracking-tighter">
			{data ? `${views.toLocaleString()} views` : '--- views'}
		</p>
	)
} Conclusion Now we have a working page views counter that is connected to our Turso database. You can use this method to add page views to any website that is built with Next.js. This article was . For more articles like this, . Real-time page views with Next.js, Turso and Drizzle ORM originally posted on News47ell.com click here

How to Add Real-time Page Views to Your Next.js Website

React does not need any introduction at all, and here I am not going to include a description of what and how it works. I tried to cover in more detail the main aspects of the React application architecture, which in the future will help you build an easily scalable project very quickly. We have developed exactly the architectural part of building applications using React Router v6. Also, I am going to use and at the end of the article, you can get the GitHub link to the repository. styled-components Application Structure Before starting any programming manipulations, it is better to accurately determine all routes in the application that will be involved. The research is better with some diagrams plan where you can see the whole general picture of your application. Also, it’s important to be clear about which routes have to be protected. Protection means when the user has access to a specific route only if he has authorization. If you are not authorized, other words are not logged in, then you can’t have that access to that route. And also a very important part of redirections. For example, if you have the authorization, what has to happen if you will go to the home route? Should you be redirected and where? All of those are to be identified at the beginning. Let’s take a look at the diagram with the application routing schema. redirection rules Initially, it’s important to divide protected and public routes. Here the green color means public and red is protected. Also, you can find some green boxes with protected paths, which means those protected routes will be with a different logic of redirection. Redirection has to happen to the first step if you came to the second step of registration without providing dates on the first step. Composition Navigation is something common among all routes but depends on the . The stack of links will be different if the user got authorization. In that way, all routes are better to wrap up to where you gonna have the logic of lifecycle and session injection, and, of course, what to show up in header navigation. It’s important to understand the state depends on the authorization. session MainLayout In our case, all components except and component depends on the . That means there is going to show before exposing the component in order to be clear on what to render. The folder structure contains a bunch of components, constants, and fakes for making API calls. View NotFound Navigation session Loader application-architecture-boilerplate
    ├── package.json
    └── src
        ├── App.js
        ├── __mocks__
        │         └── db.mock.js
        ├── components
        │         ├── Footer.js
        │         ├── Loading.js
        │         ├── MainLayout.js
        │         ├── Navigation.js
        │         ├── ProtectedRoute.js
        │         └── PublicRoute.js
        ├── constants
        │         └── index.js
        ├── fake
        │         ├── fakeApi.js
        │         └── fakeCache.js
        ├── hooks
        │         └── useSession.js
        └── index.js Data Request As you can see that we going to use a fake API for our application. In reality, it can be an Apollo Client or REST API call, but in our case, we going to use a with for request delay. We have to take care of our authentication for login and logout and request the current session from a fake API. Eventually, it’s a simple class with amount useful methods. Promise Timeout 1s import { db } from 'src/__mocks__/db.mock';
import { fakeCache } from './fakeCache';

class FakeApi {
  static REQUEST_TIME = 1000;
  static KEY_CACHE = 'cache';
  static DB = db;

  context = {};

  constructor() {
    const context = fakeCache.getItem(FakeApi.KEY_CACHE);
    if (context) {
      this.context = context;
    }
  }

  static userById = id => FakeApi.DB.find(user => user.id === id);

  #asyncRequest = callback =>
    new Promise(resolve => {
      setTimeout(() => {
        const result = callback();
        resolve(result);
      }, FakeApi.REQUEST_TIME);
    });

  getSession() {
    return this.#asyncRequest(() => this.context.session);
  }

  login() {
    this.context.session = FakeApi.userById(1);
    fakeCache.setItem(FakeApi.KEY_CACHE, this.context);
    return this.getSession();
  }

  logout() {
    this.context = {};
    fakeCache.clear();
    return this.#asyncRequest(() => null);
  }
}

export const fakeApi = new FakeApi(); You can find out that in the we are using cache. It’s because our request has to have a cache for responses and use the cache as an advance for the next requests to improve performance. This implementation is quite crude and simple, but it’s easy to get the gist of it. constructor The flow is, that once we call, we have to create a session, and clears the session and cache as well. Each should have an as fake delay for our request. But what about the cache? logout asyncRequest REQUEST_TIME export const fakeCache = {
  getItem(key) {
    return JSON.parse(localStorage.getItem(key));
  },

  setItem(key, value) {
    localStorage.setItem(key, JSON.stringify(value));
  },

  clear() {
    localStorage.clear();
  },
}; For the storing / caching data, we going to use the . This is just a simple object with methods, nothing else. localStorage Routing The router part has to care our and routes. Redirections have to happen from when we trying to access and when if the user goes to some private route without a session, it has to have the redirection to . Private Public Private /login /login "/" // -> Home view depends on session
"/about" // -> About show with session and without
"/login" // -> Login show with without session only
"/signup" // -> Sign Up show without session only
"/forgot-password" // -> Forgot Password show without session only
"/account" // -> User show with session only
"/settings" // -> Settings show with session only
"/posts" // -> Posts and nested routes show with session only
"*" // -> Not Found show without dependencies at all You can see the comment against each route described the behavior of accessibility. What’s the reason to be in if you have already a session? I’ve seen many times that issue in other projects. So, in our case, we going to have a redirection and from and from . Only should have full access in the end. SignUp ProtectedRoute PublicRoute NotFoundView <Routes>
  <Route element={<MainLayout />}>
    <Route path="/" element={<HomeView />} />
    <Route path="/about" element={<AboutView />} />
    <Route
      path="/login"
      element={<PublicRoute element={<LoginView />} />}
    />
    <Route
      path="/signup"
      element={<PublicRoute element={<SignUpView />} />}
    />
    <Route
      path="/forgot-password"
      element={<PublicRoute element={<ForgotPasswordView />} />}
    />
    <Route
      path="/account"
      element={
        <ProtectedRoute
          element={<ProtectedRoute element={<UserView />} />}
        />
      }
    />
    <Route
      path="/settings"
      element={<ProtectedRoute element={<SettingsView />} />}
    />
    <Route path="/posts" element={<ProtectedRoute />}>
      <Route index element={<PostsView />} />
      <Route path=":uuid" element={<PostView />} />
    </Route>
  </Route>
  <Route path="*" element={<NotFoundView />} />
</Routes> As you can see that we added protection for both flows. going to navigate to in the case when no session and will redirect to , because has to check for authorization. ProtectedRoute /login PublicRoute / HomeView const HomeView = () => {
  const session = useOutletContext();
  return session.data ? <ListsPostsView /> : <LandingView />;
}; The possible to get the right form it’s because will provide that . session useOutletContext() MainLayout context Main Layout Everything is wrapped in which going to provide the of the and other global-related data. For we going to use the common and under will expose all routes. Let’s take a look at the setup. MainLayout context session MainLayout Route Outlet const MainLayout = ({ navigate }) => {
  const session = useSession();

  return (
    <StyledMainLayout>
      {!session.loading ? (
        <div>
          <Navigation session={session} navigate={navigate} />
          <StyledContainer isLoggedIn={!!session.data}>
            <Outlet context={session} />
          </StyledContainer>
        </div>
      ) : (
        <Loading />
      )}
      <Footer />
    </StyledMainLayout>
  );
}; The has no dependencies of state and we going to render it all the time. But and all nested routes have to have access the . Here is the which render the child route elements and where to pass the to all children. Footer Navigation session Outlet context The request which provides us with the data has a delayed response and in that case, we show the component. session Loading Session When the application is mounted, we must request the current . The hook will fire on the mount and get the either from the cache or from the API. session useSession session export const useSession = () => {
  const cache = fakeCache.getItem(SESSION_KEY);
  const [data, setData] = useState(cache);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    if (!cache) {
      setLoading(true);
    }
    fakeApi
      .getSession()
      .then(session => {
        if (session) {
          setData(session);
          fakeCache.setItem(SESSION_KEY, session);
        } else {
          setData(null);
          fakeCache.clear();
        }
      })
      .finally(() => {
        setLoading(false);
      });
  }, []);

  return { data, setData, loading };
}; Every request we are storing the response to cache, like cookies stored in real websites. Then it’s time to show depends on the with / and child components. FakeApi session Navigation Login Logout Navigation The state for is important to enable or disable buttons during the current request. If to hit better to disable all buttons in order to prevent other operations during session clearance. Navigation Logout export const Navigation = ({ navigate, session }) => {
  const [isLoading, setLoading] = useState(false);

  const onLogin = async () => {
    setLoading(true);
    const sessionData = await fakeApi.login();
    session.setData(sessionData);
    fakeCache.setItem(SESSION_KEY, sessionData);
    setLoading(false);
    navigate('/');
  };

  const onLogout = async () => {
    setLoading(true);
    fakeCache.clear();
    await fakeApi.logout();
    session.setData(null);
    setLoading(false);
    navigate('/');
  };

  return (
    <StyledNavigation>
      <Link to="/">Home</Link>
      {session.data ? (
        <div>
          <Link to="/posts">Posts</Link>
          <Link to="/settings">Settings</Link>
          <Link to="/account">My Profile</Link>
          <button disabled={isLoading} onClick={onLogout}>
            {isLoading ? 'loading...' : 'Logout'}
          </button>
        </div>
      ) : (
        <div>
          <Link to="/about">About</Link>
          <Link to="/signup">Sign Up</Link>
          <button disabled={isLoading} onClick={onLogin}>
            {isLoading ? 'loading...' : 'Login'}
          </button>
        </div>
      )}
    </StyledNavigation>
  );
}; Private and Public It is clear that the routing should be protected depending on the , but how do get the in each Route Component? We will still come to the aid of the context provided by API. session context useOutletContext() react-router export const ProtectedRoute = ({ element }) => {
  const session = useOutletContext();
  return session.data ? (
    element || <Outlet />
  ) : (
    <Navigate to="/login" replace />
  );
}; For the everything is almost the same but another way around with a different redirection route. PublicRoute export const PublicRoute = ({ element }) => {
  const session = useOutletContext();
  return session.data ? <Navigate to="/" replace /> : element || <Outlet />;
}; Possibly you can see, that better to have something like a where is better to provide only the route of redirection and prop to identify is it a or . I prefer to separate such logic for future scalability. And this is pretty much that’s it. SmartRoute public private Conclustion React Router is the most popular routing solution for React applications and provides the most obvious and clear API for developers today. Since amazing updates in the last version building a routing architecture has become much easier and more convenient. Hope this structure of the application aims to help quickly to build up the body of future React projects. Thank you. : GitHub Repository architecture-application-boilerplate

Understanding Session Management Using React Router V6

Initial Thoughts provides Feeds, which allow developers to build event-driven applications similar to social media platforms such as Instagram, Facebook, or Twitter, in a matter of days versus months or years. Stream also provides Chat, a product that enables developers to rapidly build out a fully functional chat application for everything from a one to one messaging platform similar to WhatsApp to live stream chat experiences like that seen on Twitch. Stream As of today, over 500 million (and growing) end-users rely on Stream’s services to interact and engage with applications they love — that developers have built with Stream’s technology. Ok, now that we are done with our shameless plug, we want to share some thoughts about a different part of building a tech company — developer marketing. What is it? How can you use it? In this post, we’ll outline the key areas in which Developer Marketing can help your business thrive by addressing the techniques that we have tried, tested, and practice here at Stream. The Challenge In your typical business, a sales team reaches out to businesses (B2B) or consumers (B2C). However, in today’s world, of technology startups (SaaS, IaaS, etc.), the focus of engagement has shifted towards developers (B2D), who consume API driven platforms to power their applications at scale. While developers consumers, they react differently than your typical consumer. They are even more skeptical and analytical, and they know when they are being marketed to and are turned off by the pushiness of traditional sales models and advertising. are Marketing to developers means thinking like developers (and it’s still challenging, even when you do so). Most developers are constantly reading and learning about the newest methods and technologies, so they already have a pretty good idea of what is out there and works well. Developers decide on new technologies to use by experimenting and building to find pain points, ways around them, and to later share findings within their communities. They need to see the technologies in action and play with them in low-risk, “curiosity” scenarios before making the decision themselves to bring them into their core stacks (be it for personal or professional use). Here at Stream, our core userbase consists of developers. In fact, it’s 95–100% of our core userbase, and the majority of us are developers, as well. Because of our own experiences with “being marketed to” and finding the technologies we now use, our Developer Marketing team spends a tremendous amount of effort towards connecting and collaborating with fellow developers. This is not just to win them over, but to ensure that their experience with our product, APIs and SDKs is nothing less than amazing. Strategy #1 — Create the Connection Developers are inherently skeptical and want to try your product first hand. Here at Stream, we put an immense amount of effort towards creating API walkthroughs that allow developers to easily guide themselves through how our API works. In fact, our efforts paid off when we one the for our unique onboarding process. Programmable Web’s Developer Experience award For example, our guides the developer through the process of creating a chat application with a hands-on approach. It focuses on what developers want to see — code and the underlying SDKs that power the chat product. In less than 3 minutes, developers have a solid and fundamental understanding of how our chat product works. Stream Chat API tour We do the same for by guiding users through the process of creating users, adding an activity, and so on. This process creates a connection between Stream and our end-user, the developer. We do this because for the longest time software was built to attract product and purchasing managers who were managing a development team. Instead, we focus on putting the developer first. Stream Feeds In addition to our live onboarding guides, we have several API tutorials that show developers how to build on top of Stream Feeds or Chat with Android, iOS, React and React Native. These are regularly tested to ensure that they are always in working condition. Never “set it and forget it” and always be one step ahead of your code should things go awry. Strategy #2 — Blogging Blogging has always been a traditional way to get the word out about your company. The problem is that too many companies try to sell their company too hard in the process. To developers, this doesn’t provide an analytical justification to purchase or even use their offering. It actually comes across with a negative connotation. Remember, developers do not like to be marketed to. They can smell it from a mile away, and they hate it. Rather than writing a blog post about your company and all of the bells and whistles that your product offering comes with, try speaking the same language as your core developer audience. Write about common use-cases, development stacks, your engineering team, anything that doesn’t smell like marketing fluff. At Stream, we have a wide variety of blog posts ranging from the time it takes to buy and implement Stream vs. build the product from scratch to how we migrated from one language to another. These are the types of posts that win developers over and allow you to establish trust and, eventually, a relationship. The rule of thumb with a blog post is to give 90–95% of your wisdom away for free and hopefully, that proves your expertise as a thought leader in the space. Because you are perceived as an expert, you won’t have to actively “sell” to the developer; instead, it’s a collaborative requirement gathering to execute together. Submit your blog posts to publications on such as , or where developers will discover your content, fire off a Tweet or two, make yourself known and developers will come to you — as long as you’re not too pushy in your writing. Medium Better Programming Dev.to Strategy #3 — Live Like a Developer Live where developers live. Developers are a rare breed. They spend the vast majority of their time on the internet, pushing code to GitHub, reading through hundreds of links on , trolling , and believe it or not, blogging about their latest accomplishments on platforms such as . Hacker News Reddit Medium Now, I’m not a huge fan of advertising for the reasons listed above, but newsletters work great and will help your marketing team gain company exposure among developers — if you hit the right channels. Cooper Press is a great source for finding developer-focused newsletters that have both a high open and click rate. Depending on what we are promoting, we vary what we channel we promote on, but React and Mobile weekly have done exceptionally well for us recently. Strategy #4 — Swag, Swag, Swag Every developer loves swag. That means anything from t-shirts to stickers and even socks! If you’re going after a specific company and want them to use your product, surprise them with some swag to make them feel loved. Recently, the team over at Heroku sent Stream a box of t-shirts and Heroku branded socks. While it may seem silly, this won over our developers and we’re now using Heroku for some of our services. A great service for this is . Swag.com On the other hand, LinkedIn reached out about their recruiting tool by sending our team a 16x16” book with fun facts about their software. Although nice, that was received by laughter within the office. Although this was meant for a business representative, nobody wants a book full of information about your product. It goes without saying, but please don’t do this. Final Thoughts Let’s face it; marketing to developers is not an easy feat. You need to live, breathe, and think like a developer. And more importantly, you shouldn’t overdo it, or you will come across as desperate. With a small team, you can make serious moves from a developer marketing standpoint. You simply have to follow the steps above. Happy developer marketing! ✌️

Developer Marketing Guide: 2020 Version

o-lap.org O-LAP is an open-source community run platform for designers to experiment with parametric furniture design. It is part exploration into a new way in thinking and working with design.Designers create parametric furniture designs as plugins into the framework.Registered designs gets displayed in the .Users can the designs from the gallery and customize it based on the customization enabled by the designer.The framework lets users extract CAD drawings which can be used to fabricate the design using a Computer Numerically Controlled(CNC) cutting machine.The community moderates the design collection.O-LAP is the name for the concept, the framework and the community. gallery view Demo New Way to Design The concept is popular in design and architecture circles. If you Google terms like “ ” or “ ” you should be able to find more examples. This project uses JavaScript to allow designers to create such designs in the browser which anyone can download and fabricate. parametric furniture cnc furniture It is a new way to think about furniture design and experiment with new ideas. We are just as curious to see what can be done. Furniture designs currently have a high entry barrier due to the resources required to manufacture at scale. A designer needs to establish a studio/fabrication infrastructure or align with larger companies to try to bring his/her designs to the market.With our production process, we can enable more upstarts to present their designs and let the community decide. A community curated design collection. The designs are exported as Computer Aided Design (CAD) files by the web app, which can be used for fabrication wherever needed using high precision machines. Sending a chair can mean just emailing the design file to any location. Sending chairs across geographies is like emailing a file. We promote an open licensing system to allow all designs to be replicated and forked by anyone. A design can be copied and morphed in different ways by different people adapting the design for their use. It’s like a natural selection process for designs. A framework for evolving designs. All aspects of the design are open and recorded publicly as the design develops. The designs stay ‘honest’ in concept as the narrative is recorded at every step. The exact contributions of different collaborators is recorded in the process. Public development records log the design narrative as decisions are made. The design, manufacture and supply chain has been a closed loop system owned entirely by individual entities.By breaking apart these aspects we think we can involve more independent participants to contribute and gain from this process while still keeping the whole process sustainable. Wider community participation in the design and production process. Current Stage This is at a proof-of-concept stage. I am excited about the possibilities and exploring who else finds this cool. If you think this is cool, please sign up with us and help us spread the word. o-lap.org Github Amit Nambiar Credit for all icons goes to following awesome designers from Noun Project.I Putu KharasmayadiVectors MarketDanil PolshinEliriconBen DavisAnanthWawan HermawanXinh Studio✦ Shmidt Sergey ✦Bohdan BurmichNicolas Weidinger

O-LAP: Community for making furniture with JavaScript

If you have stumbled upon this post you probably ran into the same issues I did when working with flow coordinators. If you are new to coordinators I suggest you read posts about coordinators. This work is the foundation of my understanding coordinators but upon trying to implement my own coordinators I ran into a huge flaw when dealing with the back button. Soroush Khanlou’s Blog Horizontal vs. Vertical Flows Child coordinators can represent either vertical or horizontal flows. A child coordinator that you present is a and upon its completion you dismiss it and deallocate the coordinator. An example of a vertical flow would be an authentication flow that is presented modally and only completes when the authentication is cancelled or the user is authenticated by a login or signup. vertical flow A child coordinator that you push to is a and upon its completion (either from an action or the back button) it is popped from the navigation controller stack and deallocated. For this to work, a parent and child coordinator need to share the same navigation controller. This case arose for me when pushing to a profile page. There were many other sub flows on this profile page so I could not simply instantiate a new profile view controller and push to it whenever I wished. I needed a reusable coordinator that I could push to. horizontal flow Implementing this involves passing around a reference to a UINavigationController and a lot of messy code dealing with the navigation controller’s delegate to determine when the back button was pressed so you can deallocate the child coordinator. I began searching for a better way and I came across which included a new component to the architecture: the . You should read that as well because I will not cover all of it for the sake of brevity. Andrey Panov’s coordinator implementation Router The router is a pretty simple concept. It is a class that wraps a UINavigationController and you pass it around between coordinators. It handles the physical navigation whereas the coordinator handles flow logic. There is one router for each horizontal flow and it may be shared by child coordinators for horizontal flows via dependency injection. Every time you have a new vertical flow (usually modally presenting a flow) this will require instantiating a new router. The back button is the biggest pain when using either Khanlou or Andrey Panov’s approach for horizontal flows. Khanlou even had an entire follow up post regarding the use of together. I find these proposed solutions acceptable but still not ideal. Back Buttons and Coordinators The first suggestion invloves creating a Navigation Controller class that is a subclass of UIViewController with the purpose of enclosing the navigationController, conforming to UINavigationControllerDelegate, and maintaining a mapping from view controller to coordinator so the coordinator may be deallocated upon popping the view controller. This seems like subclassing a UITabBarController to avoid putting the setup logic of our app in the AppDelegate. Does it work? Yes, but it doesn’t feel right. He goes on to say “My primary concern is that the NavigationController class, which is a view controller, knows about and has to deal with coordinators”. The second approach involves extending the coordinator to become the navigation controller delegate and then handling deallocation when this delegate method fires. The biggest drawback of this is that there is no way to handoff the responsibility of being the navigation controller delegate to subsequent child coordinators. If you push to a child flow and then push to another flow, the first flow receives the pop events for both of the flows. I’m not sure if this approach is feasible for pushing more than one level deep. I think a combination of these two approaches would work better. What if we extend our Router class to conform to UINavigationControllerDelegate so the router can handle all the events for the navigation controller it wraps and delegate the responsibility fo what to do on the back button event back to the coordinator that pushed this coordinator in the first place? In my opinion, the ideal solution should… 1. allow us to treat the back button of a horizontal flow like we would a cancel button on a vertical flow 2. avoid polluting navigation (router) with flow logic (coordinators) 3. delegate what to do when the back button is pressed (deallocation of child coordinator) back to the parent coordinator 4. provide a common interface for presenting and pushing coordinators and view controllers 5. allow us to push to subsequent horizontal flows with ease In my opinion it should look something like this: let coordinator = ProfileCoordinator(router: router, store: store, profile: profile) addChild(coordinator) router.push(coordinator) { [weak self, weak coordinator] in// This executes when the back button is pressedself?.removeChild(coordinator)}coordinator.start() We should be able to interact with the router the same for both coordinators and view controllers: let viewController = UIViewController()router.push(viewController) {// This executes when the back button is pressed} So our push function needs to take a common type and our router needs to keep track of the callbacks so it can execute them when the back button is pressed. Our common type is the Presentable protocol: public protocol Presentable {func toPresentable() -> UIViewController} // UIViewController is already a presentable typeextension UIViewController: Presentable {public func toPresentable() -> UIViewController {return self}} Now our Router interface and implementation (This is a modified version of Andrey Panov’s implementation to provide back button support): import UIKit public protocol RouterType: class, Presentable {var navigationController: UINavigationController { get }var rootViewController: UIViewController { get }func present(_ module: Presentable, animated: Bool)func push(_ module: Presentable, animated: Bool, completion: (() -> Void)?)func popModule(animated: Bool)func dismissModule(animated: Bool, completion: (() -> Void)?)func setRootModule(_ module: Presentable, hideBar: Bool)func popToRootModule(animated: Bool)} final public class Router: NSObject, RouterType, UINavigationControllerDelegate { private var completions: \[UIViewController : () -> Void\]  
public var rootViewController: UIViewController...  
public unowned let navigationController: UINavigationController

public init(navigationController: UINavigationController) {  
    self.navigationController = navigationController  
    self.completions = \[:\]  
    super.init()  
    self.navigationController.delegate = self  
}

public func toPresentable() -> UIViewController {  
    return navigationController  
}

public func present(\_ module: Presentable, animated: Bool) {  
    guard let controller = module.toPresentable() else {   
        return  
    }

    navigationController.present(controller, animated: animated, completion: nil)  
}

public func dismissModule(animated: Bool, completion: (() -> Void)?) {  
    navigationController.dismiss(animated: animated, completion: completion) } public func push(\_ module: Presentable, animated: Bool = true, completion: (() -> Void)? = nil) {

    // Avoid pushing UINavigationController onto stack  
    guard let controller = module.toPresentable(),   
        controller is UINavigationController == false else {  
        return  
    }

    if let completion = completion {  
        completions\[controller\] = completion  
    }

    navigationController.pushViewController(controller, animated: animated)  
}

public func popModule(animated: Bool = true)  {  
      
    if let controller = navigationController.popViewController(animated: animated) {  
        runCompletion(for: controller)  
    }  
}

public func setRootModule(\_ module: Presentable, hideBar: Bool){  
    guard let controller = module.toPresentable() else {   
        return  
    }

    navigationController.setViewControllers(\[controller\], animated: false)  
    navigationController.isNavigationBarHidden = hideBar  
}

public func popToRootModule(animated: Bool) {  
    if let controllers = navigationController.popToRootViewController(animated: animated) {  
        controllers.forEach { runCompletion(for: $0) }  
    }  
}

fileprivate func runCompletion(for controller: UIViewController) {  
    guard let completion = completions\[controller\] else {  
        return  
    }

    completion()  
    completions.removeValue(forKey: controller)  
}

// MARK: UINavigationControllerDelegate  
public func navigationController(\_ navigationController: UINavigationController, didShow viewController: UIViewController, animated: Bool) {  
      
    // Ensure the view controller is popping  
    guard let poppedViewController = navigationController.transitionCoordinator?.viewController(forKey: .from), !navigationController.viewControllers.contains(poppedViewController) else {  
         return  
    }

    runCompletion(for: poppedViewController)  
} } Our router should be able to perform all possible navigation actions. It must also act as the delegate of the navigation controller so it can intercept back button presses and run the corresponding completion handler for the view controller that was popped. When a Presentable type is pushed, we gain access to the view controller to be pushed using the and store the completion handler in a dictionary with the key being the view controller. When a view controller is popped, either from the back button, the navigation controller delegate function determines which view controller was popped and executes the corresponding completion handler. module.toPresentable() Now our Coordinator interface and implementation: public protocol Coordinatable: class, Presentable {var router: RouterType { get }var onCompletion: (() -> Void)? { get set }func start()} open class Coordinator: NSObject, Coordinatable { public var childCoordinators: \[Coordinator\] = \[\]  
public var router: Router

public init(router: Router) {  
    self.router = router  
    super.init()  
}

open var onCompletion: (() -> Void)?

open func start() {}

public func addChild(\_ coordinator: Coordinator) {  
    childCoordinators.append(coordinator)  
}

public func removeChild(\_ coordinator: Coordinator) {  
    if let coordinator = coordinator,   
        let index = childCoordinators.index(of: coordinator) {  
        childCoordinators.remove(at: index)  
    }  
}

// Make this function open so we can override it in a different module  
open func toPresentable() -> UIViewController {  
    return router.toPresentable()  
} } Our Coordinator must implement Presentable so the router can present it. This default implementation will return the router’s presentable form which will just return the router’s underlying navigation controller. This works great when presenting a coordinator for a new vertical flow, but we cannot push such a coordinator. So to push child coordinators for horizontal flows we must override to give us a view controller instance that will work when we call . Note: In our Router, we guard to make sure the view controller we are pushing is not a UINavigationController. toPresentable() router.push(coordinator) So a subclass of Coordinator that we want to use for horizontal flows might look something like this: import Foundation open class ProfileCoordinator: Coordinator { fileprivate let store: StoreType  
fileprivate let profile: Profile

lazy var viewController: ProfileViewController = {  
    let viewModel = LocationProfileViewModel(profile: profile)  
    return ProfileViewController(viewModel: viewModel)  
}()

public init(router: RouterType, store: StoreType, profile: Profile) {  
    self.store = store  
    self.profile = profile  
    super.init(router: router)  
}

open override func start() {}

open override func toPresentable() -> UIViewController {  
    return viewController  
} } And voila! We can push this child coordinator from a parent coordinator and deallocate it with ease: let coordinator = ProfileCoordinator(router: router, store: store, profile: profile) addChild(coordinator) router.push(coordinator) { [weak self, weak coordinator] in// This executes when the back button is pressedself?.removeChild(coordinator)}coordinator.start() Hopefully this was helpful. This solution will work best if you use closures for the callbacks of your coordinators rather than delegates. Any feedback, questions, or criticism is welcome. Check out for a demo. CoordinatorKit

Coordinators, Routers, and Back Buttons

1- Setting your credit card information in heroku 2- Install addon scheduler Installing addon scheduler under the project directory, to activate the service for this specific project $ heroku addons:create scheduler:standard 3- Setup script Click of top green box install add-ons Set up the script you would like to run npm run postVideo Reference https://devcenter.heroku.com/articles/scheduler https://devcenter.heroku.com/articles/scheduled-jobs-custom-clock-processes

3 Step Setting up Heroku schedule (cron) job

: 08/02/2016 Latest Update Previous Post in this series _Latest Update: 08/02/2016_medium.com Writing a Blog Engine in Phoenix and Elixir: Part 6, Markdown Support Current Versions : v1.3.1 Elixir v1.2.0 Phoenix: v2.0.2 Ecto: Where We Left Off Our blogging application now supports using a nice little markdown editor to make our posts even prettier, so it’s really starting to look like a full-featured project! One thing we don’t have, though, is any way to receive any sort of feedback on any of the posts we write. The good news is this is a pretty simple thing to add and just builds on a lot of the work with associations that we’ve already built! We’re going to start very simple on this initial approach. We’re not going to worry about requiring users to register; instead we’re going to have new comments get added into a “pending” state. Comments are not displayed on the Post unless they’ve been approved out of that pending state unless the user visiting our blog checks a “Show Unapproved” button. Adding Our Comments Model Let’s start by adding a model for our comments. We’re expecting comments to have the following: An author (we’ll use string for this) A body (we’ll use text for this) An approved flag (we’ll use boolean for this, defaulting to false) The post the comment is for (we’ll use reference for this) We don’t want to create the full suite of templates and everything, so we’re going to stick to using for this. mix phoenix.gen.model mix phoenix.gen.model Comment comments author:string body:text approved:boolean post_id:references:posts And then we’ll migrate our DB: mix ecto.migrate Associating Comments With Posts If you open up you can see that Comments are now already associated with Posts, but we haven’t done anything to set that up in reverse. web/models/comment.ex In , add the following to your “posts” schema definition: web/models/post.ex has_many :comments, Pxblog.Comment And now just to make sure everything is working as we expect, run to verify that everything is still green (it should be at this point)! Now let’s modify our tests slightly so that we can test the association between a Post and a Comment. mix test First, open up and add a Comment factory. Add the following at the top with the rest of our alias statements: test/support/factory.ex alias Pxblog.Comment And add the following at the bottom of the project: def comment_factory do%Comment{author: "Test User",body: "This is a sample comment",approved: false,post: build(:post)}end Accordingly, we need to add some tests to take advantage of this new factory. Open up and add the following to the file: test/models/comment_test.exs import Pxblog.Factory # ... test "creates a comment associated with a post" docomment = insert(:comment)assert comment.post_idend Run our tests again and we should remain green! Adding Our Routes For Comments We’ll start by setting up our initial routes that we’ll be using for comments, which will help us create an initial technical design of sorts. Open up : web/router.ex resources "/posts", PostController, only: [] doresources "/comments", CommentController, only: [:create, :delete, :update]end Comments really only make sense in the context of posts, so we’re going to nest comments underneath posts. However, in the other routes, we’ve already defined the Posts resources nested under users! We don’t want to expose a bunch of post-only routes, so we use the code to lock out any root level post routes. Then we add the comments resources, but for right now, we’re only going to allow , , and . Create will be what anonymous users use to create comments (that are initially unapproved). Delete will be for the author of the post or admins to delete a post, and update will be used to allow an admin or author to update a comment to approved so it can be seen by the general public. only: [] :create :delete :update Adding Our Comments Controller and View Now that our models are set up, we need to build a controller with a couple of actions. Most of the showing/viewing comments is going to be via the Posts controller, but we’ll need to be able to delete/update/create comments from this controller in time. We’ll begin by creating : web/controllers/comment_controller.ex defmodule Pxblog.CommentController douse Pxblog.Web, :controllerend And we’ll create a view as well to keep Phoenix happy with us. Create : web/views/comment_view.ex defmodule Pxblog.CommentView douse Pxblog.Web, :viewend Now we’ll head back to the controller and start off with a very basic structure of our three actions, , , and . create update delete def create(conn, _), do: conndef update(conn, _), do: conndef delete(conn, _), do: conn Next, we’ll need a comment form template that we can use on the Show Post page. Create a new directory for us to work with: $ mkdir web/templates/comment Allowing Users To Post Comments We’ll start by creating : web/templates/comment/form.html.eex <%= form_for @changeset, @action, fn f -> %><%= if @changeset.action do %><div class="alert alert-danger"><p>Oops, something went wrong! Please check the errors below.</p></div><% end %> <div class="form-group"><%= label f, :author, class: "control-label" %><%= text_input f, :author, class: "form-control" %><%= error_tag f, :author %></div> <div class="form-group"><%= label f, :body, class: "control-label" %><%= textarea f, :body, class: "form-control", id: "body-editor" %><%= error_tag f, :body %></div> <div class="form-group"><%= submit "Submit", class: "btn btn-primary" %></div><% end %> Pretty standard form here, so not much we need to discuss. Now let’s head to the show post template , where we’ll add a reference to the comment form. Please note that in the template above, we define and , so we’ll need to cycle back to later. web/templates/post/show.html.eex @changeset @action web/controllers/post_controller.ex For right now, let’s stick with . After the list of attributes for the post, add the following line: web/templates/post/show.html.eex <%= render Pxblog.CommentView, "form.html", changeset: @comment_changeset, action: post_comment_path(@conn, :create, @post) %> We need to reference the “form.html” render inside of our View, so we specify that as the first argument to the “render” call. We need to pass it a (which we haven’t set yet, but will soon) and an action, which is where the comments should get posted to. CommentView @comment_changeset And now we’ll head to to make it all work. You’ll need to change the “show” function to resemble the following: web/controllers/post_controller.ex def show(conn, %{"id" => id}) dopost = Repo.get!(assoc(conn.assigns[:user], :posts), id)comment_changeset = post|> build_assoc(:comments)|> Pxblog.Comment.changeset()render(conn, "show.html", post: post, comment_changeset: comment_changeset)end Now let’s go back to our CommentController ( ) and flesh out the create function a little more. We’ll need some stuff at the top for a standard create function, so we’ll start by adding the following to the top (right before our functions): web/controllers/comment_controller.ex alias Pxblog.Commentalias Pxblog.Post plug :scrub_params, "comment" when action in [:create, :update] We’re including “update” in the scrub_params call because we’ll need that later anyways. Now, we’re going to hop down to the create function and replace it with the following: def create(conn, %{"comment" => comment_params, "post_id" => post_id}) dopost      = Repo.get!(Post, post_id) |> Repo.preload([:user, :comments])changeset = post|> build_assoc(:comments)|> Comment.changeset(comment_params) case Repo.insert(changeset) do{:ok, _comment} ->conn|> put_flash(:info, "Comment created successfully!")|> redirect(to: user_post_path(conn, :show, post.user, post)){:error, changeset} ->render(conn, Pxblog.PostView, "show.html", post: post, user: post.user, comment_changeset: changeset)endend We first only want to try to create a comment when we’ve been passed comment params and the post_id, since without both of those we cannot create a new comment. Next, we fetch the associated post (remember to preload both the user and comments, since our template will start referencing both!) and start creating a new associated changeset. We start off with the post and pipe that into , which builds an associated schema by specifying the association via an atom. In this case, we want to build an associated . We then pipe that into the Comment.changeset function with the comment_params we pattern matched. The rest of this is business as usual with one exception: build_assoc comment The error condition is a little complicated because again, we’re trying to use another View’s render. We first pass the connection, then the appropriate View to use ( in our case), the template we want to render, and then since that template uses , , and , we need to supply the three. Now you can test it out: if it posts with errors, you’ll get the error listing for the comment right on the page. If it posts without errors, you’ll get a blue flash message at the top! Great progress! Pxblog.PostView @post @user @comment_changeset Adding A Comments Display To Our Posts Next, we need to make it so we can actually see the posts on the template. We’re going to create a shared template that can be used if we ever want to display comments in other places for different things, so we’re going to create and fill it with the following: web/templates/comment/comment.html.eex <div class="comment"><div class="row"><div class="col-xs-4"><strong><%= @comment.author %></strong></div><div class="col-xs-4"><em><%= @comment.inserted_at %></em></div><div class="col-xs-4 text-right"><%= unless @comment.approved do %><button class="btn btn-xs btn-primary approve">Approve</button><% end %><button class="btn btn-xs btn-danger delete">Delete</button></div></div><div class="row"><div class="col-xs-12"><%= @comment.body %></div></div></div> There’s not much to explain here. The approve/delete buttons aren’t hooked up yet; we’ll tackle that in the next tutorial in this series. We also need to modify the controller to preload the comments and modify the show template on Posts to include the listing of comments. First, we’ll tackle the controller updates. In , in the function, we’ll add one line to the line that fetches the post (I’ve bolded the new line): web/controllers/post_controller.ex show post = Repo.get!(assoc(conn.assigns[:user], :posts), id) |> Repo.preload(:comments) This just ensures that our comments are loaded as part of our post. Finally, we’ll open up and add the section of our template that displays comments: web/templates/post/show.html.eex <div class="comments"><h2>Comments</h2><%= for comment <- @post.comments do %><%= render Pxblog.CommentView, "comment.html", comment: comment %><% end %></div> Adding Controller Tests for Comments We can’t leave yet, since we still have some conditions not well-covered by tests! We should cover the controller’s create function and we’ll stick to one positive case and one negative case, since those are the paths that our code will travel through. Create and let’s begin: test/controllers/comment_controller_test.exs defmodule Pxblog.CommentControllerTest douse Pxblog.ConnCase import Pxblog.Factory @valid_attrs %{author: "Some Person", body: "This is a sample comment"}@invalid_attrs %{} setup douser = insert(:user)post = insert(:post, user: user) {:ok, conn: build\_conn(), user: user, post: post} end test "creates resource and redirects when data is valid", %{conn: conn, post: post} doconn = post conn, post_comment_path(conn, :create, post), comment: @valid_attrsassert redirected_to(conn) == user_post_path(conn, :show, post.user, post)assert Repo.get_by(assoc(post, :comments), @valid_attrs)end test "does not create resource and renders errors when data is invalid", %{conn: conn, post: post} doconn = post conn, post_comment_path(conn, :create, post), comment: @invalid_attrsassert html_response(conn, 200) =~ "Oops, something went wrong"endend We’ll continue using Pxblog.Factory since it is so handy. We’ll also set up two module variables, and , same as we do pretty much everywhere else. We also create a setup block that’ll set up a default user and post for us to use to create comments with. @valid_attrs @invalid_attrs Next, we’ll create our positive test case. We post to the nested post->comment path with valid attributes, assert we get redirected as expected and that the comment was created for that post! Finally, we’ll do the same, but with invalid data, and verify that we get the “Oops, something went wrong” message that appears in the HTML when something fails validations! Done! Our current UI! Next Steps We have a great foundation for our comments, but we can definitely improve this more. For example, we still cannot approve or delete comments, and we also will fetch every single comment for a post. In the next few posts, we’ll work on refining those a little more before moving on to changing our comment system into a live comment system powered by Phoenix’s channels! Apparently I completely left off the section where we add the comments to the actual display of posts! I’ve updated this post to now properly reflect those changes :) Thanks ! Update 02/29/2016: Andrew Benz Next Post In This Series _Latest Update: 08/02/2016_medium.com Writing a Blog Engine in Phoenix and Elixir: Part 8, finishing comments Check out my new book! Hey everyone! If you liked what you read here and want to learn more with me, check out my new book on Elixir and Phoenix web development: _Learn to build a high-performance functional prototype of a voting web application from scratch using Elixir and…_www.packtpub.com Phoenix Web Development | PACKT Books I’m really excited to finally be bringing this project to the world! It’s written in the same style as my other tutorials where we will be building the scaffold of a full project from start to finish, even covering some of the trickier topics like file uploads, Twitter/Google OAuth logins, and APIs!

Writing a Blog Engine in Phoenix and Elixir: Part 7, Adding Comments Support

08/02/2016 Latest Update: Previous Post in this series Part 5: Adding ExMachina Current Versions As of the time of writing this, the current versions of our applications are: : v1.3.1 Elixir v1.2.0 Phoenix: v2.0.2 Ecto: : v1.0.2 ExMachina : 1.0.1 Earmark If you are reading this and these are not the latest, let me know and I’ll update this tutorial accordingly. Where We Left Off We’ve now added roles, users, and posts to our blogging platform, fixed up some bugs, upgraded some dependencies, and fixed our seeds. Our platform is really nice and stable and has a good set of base functionality. If you haven’t been following along or missed a step along the way, you can continue with the “11092015” branch of . https://github.com/Diamond/pxblog Implementing Markdown support Given that we’re tech people building a blog, one that we may or may not be using, we should probably allow people to write posts in something other than plaintext support. Markdown happens to be a language that works great for blogging and is really simple to support in Elixir, so let’s implement Markdown support using a third party library called . We start off simply by adding a dependency to our application in the function in Earmark deps mix.exs: {:earmark, "~> 1.0.1"} And then we’ll run to make sure we added it successfully to our application. If all goes well, we can move right on to adding support into our templates and views. mix do deps.get, compile Updating our views We’ll start by providing a convenient method to convert a post into Markdown. We don’t want to have to write all over the place, and if we ever decide to support any of Earmark’s other features and options, we’d have to rewrite that code over and over. Instead, we’ll implement a function in that will give us a single place to modify if we ever want to change that. Open that file up and add the following function: Earmark.to_html(data) web/views/post_view.ex def markdown(body) dobody|> Earmark.to_html|> rawend We have the input text, body, that we’re piping into Earmark’s “to_html” function. Since we’re expecting html out that we can place into our post, so we’ll use here. I know what you’re thinking: “yikes, isn’t raw terribly unsafe?” The answer is yes, it absolutely is. Trouble is, we need to output in raw html from Earmark, so we need to get this data rendered. We also don’t want to end up having to strip the same tags every single time we render this out, so let’s go into and add some code that will strip it out: raw web/models/post.ex def changeset(struct, params \\ %{}) dostruct|> cast(params, [:title, :body])|> validate_required([:title, :body])|> strip_unsafe_body(params)end defp strip_unsafe_body(model, %{"body" => nil}) domodelend defp strip_unsafe_body(model, %{"body" => body}) do{:safe, clean_body} = Phoenix.HTML.html_escape(body)model |> put_change(:body, clean_body)end defp strip_unsafe_body(model, _) domodelend We added a decent amount of code here, so let’s discuss what we’re doing. The first change we made is at the top, in our changeset function. We added a new call, . This will pattern match into one of three possible functions. The first includes a body parameter that is nil; the second is the method that includes a body parameter which we have to strip it out, and the third is a final catch-all. strip_unsafe_body(model, …) We use the function to replace the body change with a stripped version, which calls out to Phoenix.HTML’s “html_escape” function. This function takes in text, and then returns out a tuple of on success. put_change {:safe, cleaned_up_body} Writing this code with no tests makes me queasy, especially with what we’re doing here, so let’s test it! Writing tests for our code stripper The first thing we’re going to need to do, since we’re depending on these model actions to keep our code safe, is make sure they’re tested appropriately! defmodule Pxblog.PostTest douse Pxblog.ModelCase alias Pxblog.Post @valid_attrs %{body: "some content", title: "some content"}@invalid_attrs %{} test "changeset with valid attributes" dochangeset = Post.changeset(%Post{}, @valid_attrs)assert changeset.valid?end test "changeset with invalid attributes" dochangeset = Post.changeset(%Post{}, @invalid_attrs)refute changeset.valid?end test "when the body includes a script tag" dochangeset = Post.changeset(%Post{}, %{@valid_attrs | body: "Hello <script type='javascript'>alert('foo');</script>"})refute String.match? get_change(changeset, :body), ~r{<script>}end test "when the body includes an iframe tag" dochangeset = Post.changeset(%Post{}, %{@valid_attrs | body: "Hello <iframe src='http://google.com'></iframe>"})refute String.match? get_change(changeset, :body), ~r{<iframe>}end test "body includes no stripped tags" dochangeset = Post.changeset(%Post{}, @valid_attrs)assert get_change(changeset, :body) == @valid_attrs[:body]endend The first thing we have to modify is our declaration at the top. When we receive data from the controller it’s going to be in the form of string-based keys, not atoms, and it will cause our tests to fail unless we modify that. @valid_attrs Next, we import in , but only the function, which we need to pull the translated value out of the changeset. Finally, we write four tests: Ecto.Changeset get_change/2 When our body has a script tag in it When our body has an iframe tag in it When our body has none of the invalid tags in it Re-run our test suite and we should be green. We have one more test to write and then some a few basic UI changes and then we are complete! Writing our tests for the Markdown helper We should also write a quick test for our markdown helper function that we wrote in our Post View module. The good news is this should be a very simple test to write. Create and fill it with the following: test/view/post_view_test.exs defmodule Pxblog.PostViewTest douse Pxblog.ConnCase, async: true test "converts markdown to html" do{:safe, result} = Pxblog.PostView.markdown("**bold me**")assert String.contains? result, "<strong>bold me</strong>"end test "leaves text with no markdown alone" do{:safe, result} = Pxblog.PostView.markdown("leave me alone")assert String.contains? result, "leave me alone"endend Run our tests, verify that all is green, and we’re done with updating our tests for this new functionality! Updating our UI Right now, we have the ability to write up full posts but the UI doesn’t really support us editing anything larger than a single line. We’ll modify the standard form to include a text area instead of a textbox and we’ll also give it a shiny, better editor. Open up and add an parameter and give it an id of “body-editor”. The finished line should look like this: web/templates/post/form.html.eex id <%= textarea f, :body, class: "form-control", id: "body-editor" %> Finally, add the following code to the bottom of your form’s template ( ): web/templates/post/form.html.eex <link rel="stylesheet" href="//cdn.jsdelivr.net/simplemde/latest/simplemde.min.css"><script src="//cdn.jsdelivr.net/simplemde/latest/simplemde.min.js"></script><script>var simplemde = new SimpleMDE();</script> Reload our UI and we should see a very clean interface for writing new posts! This is starting to look like a proper blogging platform and everything! Finally, open up and change the line that displays the post’s body and change it to use the markdown(body) function we defined in the view. web/templates/post/show.html.eex <%= markdown(@post.body) %> Conclusion We now have a better means of editing/formatting our posts and the editor looks much, much nicer! We’ll probably also want to fix up the layout at some point, and there still isn’t any way to add comments, but commenting actually would be a fun way to implement support for channels, so we’ll hold off for now until we’re ready to build that support in! If you want to see the completed version of this code, just grab the “add_markdown_support” branch of our repo. Next Post In This Series Writing A Blog Engine In Phoenix And Elixir: Part 7, Adding Comments Support Check out my new book! Hey everyone! If you liked what you read here and want to learn more with me, check out my new book on Elixir and Phoenix web development: _Learn to build a high-performance functional prototype of a voting web application from scratch using Elixir and…_www.packtpub.com Phoenix Web Development | PACKT Books I’m really excited to finally be bringing this project to the world! It’s written in the same style as my other tutorials where we will be building the scaffold of a full project from start to finish, even covering some of the trickier topics like file uploads, Twitter/Google OAuth logins, and APIs!

Stories, News & Mentions about POSHVINE

Categories

Trending Topics

Stories, News & Mentions about POSHVINE

Poshvine’s Stories on HackerNoon

Categories

Trending Topics