Charles: Hey everybody and welcome to episode 125 of The Adventures in Angular show. Today’s we got on our panel we have Ward Bell.
Ward: Hello everyone.
Charles: Alyssa Nickel.
Alyssa: Hello, hello.
Charles: John Papa.
Charles: Lukas Ruebbelke.
Charles: I’m Charles Max Wood from Devchat.tv. This week we have a special guest that’s Travis Tidwell.
Travis: Hey guys. Glad to be here. Thanks for having me.
Charles: Do you want to give us a brief introduction real quick?
Travis: Yeah, of course. Thanks you. Like you said my name is Travis Tidwell, I’m the co-founder and CTO of Form.io Which is a new-ish company. We’ve been around for 2 years now and essentially what we are providing is an AngularJS and ReactJS based, frontend form solution where you can build your forms with a form builder and that generates a schema which not only renders the form in your frontend application but it also automatically generates REST APIs for data management. I’m very excited to be here to talk about serverless applications and where a lot of the experiences that I’ve had building this new applications in a new exciting world. Thanks for having me.
Charles: No problem.
Lukas: This is great. What’s a form?
Travis: Actually, it’s great that you start there because, form, it can mean a bunch of things. I actually mean it in the very literal web development sense where it’s a way for data collections. Whenever I say form, I am actually referring to an HTML that all of the developers dread which is writing the form at all of the input elements into their web application. It can also mean a structure which I almost think that the way that we apply forms at Form.io can actually mean both because you’re essentially taking the HTML input and you’re using a JSON structure or JSON form to automatically and dynamically render that form within your frontend applications. Using our form builder which a really glorified schema builder, you can create a form that then renders as an HTML in the frontend. Hopefully that answers your question of what is a form.
Lukas: It may help everyone because they don’t have diagrams. To sort of imagine something it strikes me as an obvious use case for this which is building a questionnaire. I can imagine and tell me if this is right, because it will be nice to be concrete during our talk. Tell me if this is right case for it. I’m generating questionnaire for field reps to go up there and inspect restaurants and inspect this and inspect that. They have to have this little checklist questionnaires and of course, the questionnaires are always changing because what we’re supposed to inspect today is always changing, somewhere in the background there is a metadata that determines what the questionnaire for restaurant is, what the questionnaire gasoline station is, what the questionnaire for a hotel is, that kind of thing. Is that the kind of business case that will propel what you’re talking about?
Travis: Thought on and really these questionnaires have a lot more to them, a lot of them are conditionally so you have one question could maybe drive the presence of other questions that need to be asked.
Lukas: I’m trying to keep it real simple, Travis but I get you. But it’s like the simplest problem that people can imagine is that some are questions are multiple choice, some questions have drop downs in which you select something, some have free form text. Let’s keep it real simple, like that. Use this all day long, but those of us who are listening in are familiar with that small of a problem. Let’s see what you can tell us in those terms, with those examples.
Travis: What you described, the actual use case, is spot on perfect of the use case on why you would use Form.io. You have a questionnaire where you need to have service reps filling out a web form for data collecting purposes. You are the developer, tasked to build this app in which the service rep would be using, as a developer you would like to build it to be installed on the tablet applications, of course is AngularJS, you’re going to build your application in AngularJS and you’re going to render this form, now you have a choice to make whenever you’re doing AngularJS developments. You can either a, hand code that entire form in HTML and then latch on the form of course and then hook it up to the API in the back, in which you also have to build the API to receive the data whenever they press submit or you can use a tool like Form.io. that allows you to build to a dragon drop form builder and really it’s just a, hey I want a text build and then you click on text build and you drag it over to the form that adds a text field. You say I want to drop down, you drag the text builder, so you’re using a drag and drop interface to build a form whose purpose is to be embedded in a server list app such as your AngularJS application which would essentially render that form dynamically in the application. But on top of that, it also builds the API to capture the data’s flow.
Lukas: Okay. Before we pursue that line of thought, is the process, like okay, I’m building and inspection form for a hotel to my drag and drop thing and create the definition. Now, I’m doing a gasoline station, dragging and dropping, now I’m doing a hotel room, draggy-droppy, am I building three form definitions? Is that the idea?
Travis: You are. Yep. You have the ability to create a project in Form.io and with a project you can create an unlimited amount of forms. And each form that you build would be its own simple drag and drop interface and each one of those surveys that you need even for a different purpose could be a different form in your project.
Lukas: And then you were saying that there’s a way to wire that up naturally to the data source such that it could pull in the information from a previously completed survey and or take a new field services reps entries and store it off, plucking the data out of the form.
Travis: Yup, absolutely. These forms are API driven which is the topic which is really API driven service type, API components, which is basically you have the ability to using that form schema which is actually a JSON object. You have the ability to totally render the form dynamically but that’s same JSON schema is used to auto generate the REST API that accepts the data for that form and using that same AOI as well, you can get to the data and then repopulate the form with that submission object.
What we’re doing is we’re taking this concept of when you’re building a form, you’re adding text fields and you’re adding select dropdown but you’re also adding validation criteria, what’s the min and max value for these fields, what is data content and really those same criteria are also applied when you’re trying to build an API. When you build an API you really building an interface of data, and the way that I like to tell people that if you want an easy way to explain it, if you were to put an UI on top of an API, what you would end up with is a form. The insight is here is you can use a form builder to generate, not only the form that you embed in your application but also the API on the backend to receive the data of that form. And it all just seamlessly comes and connects together. When you’re a developer building this form, you use a directive which is just an AngularJS directive that works a lot like an image tag, if you can embed this directive which is like an image tag, it has a source and the source is pointing to the API of the form. That will dynamically render that form right into your application and you don’t have to worry about it.
Lukas: You represent the metadata advice, the form as a JSON representation, is that fair to say? Is it fair to describe it as a meditative?
Travis: It is fair to say that the form definition is metadata, there’s a very popular library in Angular formally, which is a JSON powered form schema definition. But that’s really frontend application library. We’ve essentially taken the same concepts of formally on the frontend but we’ve brought it also back into an API data management platform on the project.
Lukas: Gotcha. You’re saying I can use the same metadata to draw the form and construct the API just use the same thing and so they’re always going to be in sync.
Travis: That’s correct. And then also when you make notifications, you made the comment hey when I’m making changes, I need to make changes to these forms, no longer you have to redeploy the app. In a lot of cases you have your application has been deployed or you’re using Apache Cordova to compile on actual devices and you’ve got this app in an app store. If you have to make a change to your form, you have to redeploy where if the components are dynamically rendered you make a change to the form in the form builder it automatically pulls in the change in you app and it automatically configures the REST API on the backend.
John: Did you for an instance point in at a Swagger end point and say, form create yourself and what you’re doing is in the model drive the form. You made obvious extension of this is would be, I have a REST API, line up just pointed it like Swagger notification which [00:12:06].
Travis: We actually started off by trying to use Swagger, the issue that you run into is when you’re dynamically generating a form which is HTML, as you know HTML is by nature hierarchal you can have components within components within components. And the same applies for input elements, you can actually have form within forms and input elements within input elements and you have this hierarchical nature of a structure. We actually started off trying to use Swagger, to define the form, the promise if by nature the form were very constrained and not only have a look but also how they behave. There are some things that Swagger doesn’t account for which is like conditionals to make one bit of data input conditional based on the input of other values is a good example. Because of that we were limited on trying to build a form schema definition out of Swagger. We ended up having up to use essentially a custom schema definition that’s more keen to like schema.org. But even then we weren’t able to use it because of some other limitations in Swagger. And then what we end up doing is with that schema, we generate Swagger docs from our schema because you can easily get the Swagger docs from our schema, our APIs absolutely are compatible to Swagger documentation, in fact we put a Swagger spec with the API that’s generated with our form schemas.
John: The next question I have is, what about a GraphQL model which is even more expressive, where it allows you to actually express relationship which is something that you really don’t get in REST API. I’m curious if you thought about extending a part of this model driven form world that you are talking about to absorb GraphQL models go from there.
Travis: Very recently I’ve been exposed to GraphQL and I believe that it’s a very exciting technology that has a lot of possibilities but back to years ago when we were developing Form.io, GraphQL is around at that time. As of right now I think it’s a very exciting thing that I’m willing to explore and extend the ability of integrating that capability.
John: You’re saying things all that I want to hear, my friend.
Charles: I would just imagine that there are more concerns in the form definition or there at least a difference out of concerns. The overlapping concerns for the API and the form but to be plenty of forms stuff that wouldn’t be of interest to the API and there’s probably an API stuff that’s a lot interest to form, you’re trying to create a descriptive language that covers both bases, is that fair?
Travis: Very fair. In fact a lot of the conditionals that I mentioned were one field shows up based on the values of other fields and API doesn’t actually care about, actually take that back in API may decide to accept data if the conditions are correct for that field. It uses those parameters differently, whereas the form at the frontend uses those conditions to hide and show certain elements based on input. The backend uses it in a different way and what we’ve had to do with our schemas is not be specific frontend or backend whenever we use to define them. Instead what we do is we actually put a lot of capabilities in our renders that we call the frontend library that takes the schema and renders it, which everything frontend is Open Source, in fact our core is Open Source as well. The renderers take that schema but they can also can be configured to behave a certain way and they can also be templated, you can actually override the templates form the renderers so that you can decide, let’s say you have a very custom behavior, you went out of your frontend form, you can actually override that in the rendering capabilities. In that way, you really using the separation of concerns that serverless applications gives you. Doing what you need in the frontend but at the same time doing what you need to do in the backend and you have that overlap absolutely. Whereas you [00:16:52] you have to write it twice.
Ward: I don’t know about anybody else but you lost me with the word “serverless application’”. What the heck is that?
Travis: I’d like to talk about that because it’s becoming somewhat of a board room bingo term whenever you’re in a conference room, something that you eventually you’re going to want on your bingo slap. It’s a serverless application. Let’s talk about the word serverless because I think a lot of people actually misinterpret what I means. A lot of people believe that the word serverless app that means my application doesn’t need a server. What I would like to say is that a serverless application doesn’t mean that it doesn‘t use a server. The word serverless means that the application has been liberated from the server. It’s a great way to think about it. Now instead of the application being served by the server itself and in order to really capture what I mean by that, let’s talk in terms of websites back whenever the websites originally introduced whenever you go and visit a website, you’re actually sending a request to the server. The server has been taking your request, looking for a file on its file system which is an HTML document and then sending that HTML directly to the customer. You essentially to that request, you are getting an HTML page and the server is responsible for sending the HTML page to the client and through that they actually became an evolution, now you have back in templating libraries that can dynamically generate HTML on the back and PHP became very popular in that time. And through that you have [00:18:45]. Now when you type your website and you hit enter in your browser that sends a request to the server, the server then takes PHP renders the page and still even in that scenario, sends that HTML page to the client.
Serverless application flips that whole paradigm on its head, meaning that a server doesn’t necessarily mean that your application doesn’t need a server. It just means that the server is not responsible for sending the app or the app to the client. The application can be deployed anywhere, you can deploy it in Apache Cordova, you can compile it suing Electron as a desktop application.
Ward: Isn’t that what we mean by single paged application? I might clear at the distinction.
Travis: Yes. Single paged applications really brought about this whole serverless movement but even single paged applications, there’s a lot of platform out there who still insist on the server, sending the serverless or the single paged application to the client and even certain widgets to the client so that the client itself is not necessarily liberated from the server.
What I mean by that is, let me give a good example. Some platforms like, MEAN.IO, MEAN.IO is built on a Mean stack which includes Angular but the way MEAN.IO works is it uses [00:20:32] on the backend to generate the Angular applications, whenever I am interfacing with the MEAN.IO application, I am hitting the server, the server generating an Angular app in sending me a single paged application is remarkable. How many platforms still get this wrong?
Ward: That’s a harsh choice of words. I don’t want to say get it wrong, it’s really an opinionated way of building applications. But the whole opinion of serverless is based on breaking that paradigm so that applications exist on their own and then they can be deployed on even CDS. You can host your website on an S3 bucket and by doing that, you’re really breaking the ties to have the server be responsible for sending the application and a whole world of flexibility opens up when you do that.
Lukas: The server in this paradigm becomes a place and receives data and maybe there’s some necessary business logic back there related to managing the data but it’s really about data flows and not about application artifacts. Is that fair?
Travis: I’m glad you mentioned that, because you mentioned back in data flows, one big gotcha of the server based platforms, is that they do a lot of data flows and stat changes on the server. When you operate in the server release environment, you really restrict yourself and your server to being a stateless REST API. And what I mean by that is the application itself is responsible for state changes in certain things. To give you an example, in our forms, whenever you are using Form.IO application, you are very often changing the state for resources. However the states of resources are never done on the server or the state changes. You’re doing those within the application and then using simple REST APIs to input request to update the state of certain things.
Another thing is authentication, with server side applications, the state of the application itself is determined by who is authenticated into that server. A lot of server based applications, the rendering of the HTML is dependent on who is authenticated. That’s never the case for serverless because when you’re using serverless, your authentication is quite literally what data can I get to or what APIs can I have access to. But even then you’re accessing this APIs in a stateless manner, so that you’re never really modifying state on the server. But what you’re doing is you’re turning the single paged application into a standalone app which I believe it was intended to be. The problem is just people are not utilizing it into its fullest potential. Let me put it that way.
John: I don’t think single paged app for the original [00:23:44] for HTML or even serverless apps but let’s set that thought aside. The point here is that the server doesn’t make application decisions, it still seems to me that there is a role deploy for logic, but I don’t think it has anything to do with state or state fullness at all. That the server is going to make if it’s responsible for validating data and perhaps doing some kind of calculations that should be done server side and all that stuff. That role still remains, don’t you think?
John: Anything you can do on the frontend, you should do on the frontend. Once you have butt into either the single paged paradigm or what you’re calling the serverless paradigm, the idea is to push as much computing out of the client is you can do and is allowed to happen given the business rules and stuff you got. But there’s certain kinds of things you can’t trust the client or the client doesn’t have access to the data and you shouldn’t flow all the data necessary to make the decision down to the client and that’s the kind of stuff that reserved for the services on the server, perhaps micro service.
Travis: I’ll give you a good example that put our self in the context of an example in which you are absolutely right. One is elevated permission to repurchase being made, if you’re doing subscription website or subscription app, where if they pay for something they then get elevated roles and permissions. That is a used case that you cannot do in a front end application without exposing the ability for users to upgrade their role without hang.
John: What you’re describing absolutely is true but you can solve this problem and still a stateless micro services way. The process of let’s say, a form submission being made to say I am paying for this service, on the backend essentially the way for my own works is we have a bunch middleware layers that we call actions and these actions basically perform very minimal actions on the submission before it’s committed but why the things it does is it triggers what called the webhook. Web hook has the ability to kick itself into a micro service which can also handle that request. Now where you are using Lambda and the case of subscription services to receive the web hook on the backend. It does its authentication through the payment processor but then it does a simple put request once it has validated, it has put request on the submission to elevate the permissions based on the acceptance of their payment. That’s an example where you can achieve complex backend business logic while at the same time remaining stateless from a backend perspective.
What I’m getting at is there’s a lot of backend server applications that do it right. Hopefully I’m not coming cross saying you’re doing it wrong if you’re entirely in a server based application. All I’m saying is it’s very easy to fall into what I call empty patterns of application development where your server is no longer a stateless REST API it become this mono list then you have these interconnected dependencies within your backend application. Like converting your rest API to a very simple, really resource data management system and then kicking off webhooks to micro services as need be. You really create a scale that you would not be able to achieve with a single mono list server based application.
Alyssa: Travis, just to make sure I understand, are all PWAs serverless applications or no?
Travis: Can you say what a PWA is Alyssa?
Alyssa: Progressive Web App. We could get into defining that but there’s a long list of what qualifies as PWA and what doesn’t.
Travis: What’s in your mind Alyssa as you describe that?
Alyssa: It’s a responsive web app that works for any shape and size and it also works offline. What made me think is that why does it count as serverless or is that a totally different concept?
Travis: I’m glad you actually mentioned Progressive Web Apps and I was like mobile first where you have essentially a responsive website that responds to the device. I also believe that Progressive Web Apps are API driven web apps, I believe in order to be classified as a progressive web app it should be API driven although I might be wrong about that.
Travis: But I would like to mention it. To answer your question to me, I’ll say a Progressive Web App as I know is defined is a serverless web app. It’s just another label for it.
Alyssa: Okay. That makes more sense whenever we put it in those terms because I get the concepts but I was getting a little fuzzy there.
Travis: It’s interesting that you mentioned mobile and responsiveness because if you guys remember, four years ago, the bitcoin phrase that everyone is you need to develop mobile first. And if you’re going to build an app, you needed to do it mobile first.
One very interesting thing to note about that is whenever people solve that they did not solve the serverless way, the server was still sending a web app that just so happen to resize on the person’s device.
Ward: Like media CSS.
Travis: That was a mobile first. It’s interesting because I actually think we need a new charm, in fact this charm is actually starting thrown around first when instead of thinking first. Start thinking API first when you’re building an app. Build the API, the stateless REST API and the data management capabilities and then the application quite literally just becomes an app that can sit on the top of the APIs.
Alyssa: Can you give an example from back with the form that Ward was describing if we were not going to start by building this out thinking mobile first or thinking API first, what would be one of the very first things we do?
Travis: The very first thing is to think about your data structure and you data. Whenever web application developer is, back in the day, was going to build a web app they would start thinking about their database. How do I want to structure the data? And they would come up with these database tables. It’s remarkable that those database that they use to structure that would create linking dependencies and this one is dependent on that data structure. That extra sites is still very relevant in terms of structuring your APIs.
As is turns out, whenever you’re building your data structure, in Form.io you can actually build resources but you’re using forms to do it, you’re using dragging and drop form builders but really actually building a data structure. These data structure really serves as the data interface and the database interface. Now at that point you focus on your API, build your API, in fact I always tell application developers that your first app for Your API should not be an app. Your first app should be a test, an API test. Build by using Mocha, write some API test around your API and that becomes your first application. And then once you have your API fully tested, fully automated, and it’s solved, at that point you shift our focus over to an Angular application but you build it locally on your machine, you don’t have the server send, in no way should your API engine send the application. A lot of people and a lot of platforms actually start you off constructing the app. Like CMSS, I think it’s been ingrained in developers because CMSS work this way.
Ward: I’m going to push back and unpack that a little bit. Alright? Because I’ve been around on this block a few times. There’s a part of me that’s really sympathetic because way back in the day, I won’t say when that was. We used to say that if you show me your data, I’ll tell you what your application does. That’s almost what you’re saying here, show me your API and I know what your app does. That was not a bad heuristic. But then there was some movement of what that said maybe the user experiences first. And I don’t even really know what my API should be until I worked how the users going to interact with it, what the workflow is going to be and so that does lead you to start thinking not in terms of APIs first as a service but in terms of the use to experience the front end.
Recently I come to think that it requires a balance of those perspectives and you kind of meet in the middle. When I hear you say, just get your API right, I wonder how you even know your API is if you don’t use your experiences.
Travis: I’m glad you brought this up because what if you were not correct and you just said and there would be no need for tool like Form.io? Because with API first approach you still run into the problem that you just described. Where is you have to put yourself into an application context to even know where your data can and what data is going to be structured. With that said, what Form.io actually accomplished is, is it allows you to put yourself into a data work flow type of exercise and how do I want to collect my data. To the process of building the interface which is the form, you are essentially automatically building the API that supported, without violating the API first mentality, the API first whenever you’re building your form, you’re generating the API. I think API is really the starting point, is what I want to say. I don’t want every frontend developer, you have to be an API builder to become a frontend developer. That’s not what I’m saying, what I’m saying is the starting point should be APIs and you can reflect certain API constructs in the UI in a very elegant way. And it just so happens form building is one way to do that. Whenever you’re building your data workflows, you’re envisioning your application, of course the apps that we deal with are really form based apps, which those are almost in the class vacation to themselves, If you’re building the next WhatsApp, do you really need to construct all the database and APIs, I mean you probably do but in those type of applications, the app itself could possibly define what your data structures are. It still needs to be API driven, though.
Ward: Going back to our inspection example. I’m sitting there, I’m thinking alright, are we a building the form for the hotel, we’re building the gas station, we’re building for the restaurant. You were saying that they were generating an API which implies that API is going to go create something on the server and how the data is going to be stored. I missed that connection.
Travis: It’s really hard to achieve what we did Form.io without a no sequel backend such first and foremost that’s one of the most…
John: I figures you’re going to go to a sequel.
Travis: That’s one of the most important starting points as from a database management perspective. It doesn’t mean that I’m totally against SQL based databases. However I do believe that if you need the flexibility that we offer, you need a no sequel as your starting database. Now we have a number of connectors that allows you to map schema less definitions into very structured table based definitions. But that’s a secondary request at that point.
John: Each of those different inspections for those would resolve in a different representation in a sequel database in the metadata that describe them that you’re creating for Form.io will help you also understand what it was that you had stuffed into our MongoDB to your whatever, right?
Travis: That’s exactly right. In order to really make sense of the data you need two things. One is obviously the data submission itself which is just a packet of JSON but you also need the form definition which defines what it is that stuffed in that submission. Whenever you’re loading a submission, you have some context on how is that data stored and the context is provided by a form definition which is a separate definition entirely from the submission definition.
John: It is my form evolves but my data stays behind like form version one and that form version two, your pinning the data representation and your data store to the version of the form definition that data were created?
Travis: Yes. And what’s great about it is when you’re loading a submission. You’re loading the form definition to go along with it so now your frontend application, let’s say it loads a submission that’s three versions behind, you cannot load a submission without loading the version of form to go along with it. Even then, you’re going to render the form dynamically in the version in which the submission is submitted.
John: I’m starting to see how this goes together. Imagine I have the whole thing. From a server side perspective, I need to reason across all these inspections that we’ve accumulated. Some of them taken by forms of different vintage but I’m probably inspection from all the inspectors out in the field in order to do some kind of analysis and data retrieval and searches for violations and all that other stuff, that’s something that I would do server side code, ripping over the MongoDB, right?
Travis: Actually what we’ve done is, yes, you do it on a server side but we’ve actually exposed some MongoDB facilities be it REST APIs such as the aggregation frameworks. Now you need to get to your data, you need to be able to aggregate it and funnel it to put some pipes of manipulation. One great thing our API is that our API is really almost a window into Mongo, you actually have the ability to construct using aggregation framework, aggregation API request to structure your data in the structure you needed.
John: Sure and I could imagine getting the alphabets, the CQRS world where you have some process and sweeps through you Mongo produces sequel table or whatever it is that somebody wants to have for analytics to do queries again. I get that. Let’s get closer to the frontend. With this metadata that describes the form. How you render widgets on the screen using Angular?
Travis: It’s actually much more, especially in Angular 2, Angular 2 made this way more difficult than it was in Angular 1. We’re doing this a little bit different than normal Angular app. The normal Angular app, you start off with a static HTML structure, your template of your directive for your component in Angular 2 and then you feed data into that structure. What we’ve had to do to really make dynamic HTML from a schema work is we leverage object very heavily. Every single component is essentially its own class and to find how that component looks. And then from a rendering perspective, you now have this form, this form schema is hierarchical as well, you really have this recursive iteration into the form components essentially instantiating the component class that is associated with that JSON component object. And then lets it renders itself and the in order to make all of that work, you basically have to essentially have dynamic view reps where they are dynamically pulling those rendered components into a list structure and that forms, essentially it builds HTL right in front of you, it’s what it ends up doing.
John: For the folks at home, who are learning Angular this is something that they’re not used to. This is a dynamic view construction. Let me see if I got this right. First, your first step was to say, alright we have a catalogue of widgets that we can put on this stream and each of those is which is going to be an Angular component representing some kind of representation of the data that’s on your JSON, right?
Travis: That’s correct.
John: Here’s one for the drop down, the multi choice thing, here’s one for free text entry, here’s one for checkbox, that kind of thing?
Travis: That’s correct. You have a class that is associated with each element type.
John: And then you have some way of saying, well I’ve got components, master container components into which I can dynamically plunk down, oh I guess I need to select they’re here now I need the check box from both of there and now I need to free text entry there. All guided by the JSON but you’re dropping this things in these components in dynamically into some kinds of container structures. Is that approximately right?
Travis: That’s right. And actually all of the source code is available, if anybody wants to see how we did it, it’s all Open Source on github.com/formio, one word, ford/ng2-formail and in there you’ll see that we actually you have leverage the view child view container references to essentially create a standard format element component. And the form element component will take a JSON structure that tells that form element component, here’s the type of component you should become and that form element type then loads up that component class and the replaces it’s guts with the contents of the whatever form component class as it should be.
John: If you’re playing at home, and you’ve been following the general guidance. Most people are used to writing fixed templates and there’s a bound to the component and that’s what they know because we get this question a lot like, why can’t I change the HTML component after I’ve already defined it once, why can’t I do it free form and that’s kind of the way we used to do it in Angular 1, right?
Travis: Right. Angular 1 was much easier than Angular 2.
John: It requires a different perspective. I like to think of it but the fact that we haven’t really taught this yet, we haven’t taught people how and it sounds like this is what you’re doing.
Travis: Yeah. It’s exactly. Now, all of the source code is available for anybody needs to do it and you need a pattern to establish. Again, you can go to our GitHub NG2 Formio library and there is this very special component called formioelementcomponent.ts in the source folder and that’s really the component where all the magic happens.
John: Aside from the wonders that are Formio, I want to suggest that once you actually learn how to do this, because I did this recently for the separate project of just creating a container and dropping a component into a completely driven by day driven way but from my collection of component definitions that cover the kinds of things you want to do but dynamically constructing them based on other metadata isn’t that hard to do but you do have to know how. That’s what we can teach people.
Travis: And you’re right. It isn’t hard when you learned but getting to the solution is what’s difficult.
John: Exactly. Particularly when you’re thinking you’re coming from Angular 1 space or almost any other space really that you’re supposed to deconstruct in HTML on the flock and that’s what you don’t do in the new Angular, you don’t construct a HTML on the fly, you construct component trees on the fly.
Travis: Yup. The pattern has been established. It works really well on Angular 2 and I will send the link to the actual component that does it [00:49:28] to reference.
John: I think that would certainly help people learn how this go.
Charles: Lukas, do you want to start off with picks?
Lukas: Sure. I have two picks this week. My first one is a new Flexbox Series that our friend David just started about Flexbox and zombies and has been releasing I believe a lesson a day. I’ve gotten two of them. They’re very, very good classic David and he’s probably one of the funniest people I know and also I’ve been reading Tools of Titans by Tim Ferriss and it is probably one of my favorite books ever. Actually when I went and bought 10 more copies to give out to my friends.
Charles: I haven’t received mine yet, Lukas.
Lukas: You’re going to get it. [00:50:15] out. I’m bringing you a copy buddy. It’s phenomenal, it’s basically a composition of all of his interviews and best tips and strategies that he’s learned from his podcast and I’m waiting for Chuck to actually do a version of that textile, but nonetheless great book, highly recommend it, also check out David’s Flex Box Zombie saga that he is producing. It’s pretty cool.
Charles: Alright. Alyssa, what are your picks?
Alyssa: I have a friend, Shai Reznik. Some people from Angular community probably have heard of him and he invited me to help out with his HiRez.io website where he does funny educational content. I’ll be coming out with some stuff with him soon but upcoming even sooner than that ATDD Course for Angular. Have your eyes out for that and check out HiRez.io
Charles: Very cool. We’ve had Shai on the show before so we’ll link some of those episodes too.
Ward, what are your picks?
Ward: Well, I have a pick, it’s an oldie but a goodie book that I have called Objects of Desire: Design and Society since 1750 and it’s a look at consumer goods and what the relationship is between utility and appearance and how that influences the design of objects and I just feel like something like that refreshes my thinking about the design of computer software.
Charles: Alrighty, I’ll jump in here with the couple of picks.
The first one is, it’s funny, I didn’t even know that I had it. It’s actually still in shrink wrap but I love this Moleskine notebooks. They’re just nice, they feel great. I really like them. They’re just nice well-made notebooks. I’ve taken to journaling in the morning again and I do it by hand. I don’t type it in the computer. It’s just kind of a nice thing to have and then if I need to jot something down or thing like that. Anyway, it’s a nice way to go. I’m really enjoying that.
And then I’ve also started using a system called Asana, I’m sure people have heard of it. It’s a to-do app. It’s something that I’ve been using to just keep track of all the things I have going on since I now have a few people working with me to the conference and podcast and everything else together. Anyway, great tool.
Travis, do you have some picks for us?
Travis: You put me on the spot. I don’t.
Charles: What TV show have you been wasting your time on latety?
Travis: I’ve been really into West World. If you guys are getting into West World, they just had their season finale. If anybody has not seen that, I recommend it. It’s about AI taking over the world, which I thoroughly enjoy.
John: Yes. I watched every one of those darn things and burn a lot of nights with them. I can say it’s a guilty pleasure.
Travis: It is a guilty pleasure, for sure.
Charles: The other ones that I ask if people don’t have picks is books. Are there any books that you just think everybody should read?
Travis: I don’t have any books that I can think of at the moment. I have three kids. Unless it’s going to be like Curious George.
Alyssa: What’s their favorite book?
Travis: The ones that I read are the ones I read to my books and I got burned off at book. I got the whole pinkalicious lined down because I read those to my kid.
Charles: If people want to check out Form.io or read your blog or follow you on Twitter. Where are you these days online?
Charles: We will go ahead and wrap this up. And we will catch everyone next week.