Forem: Ayaz

Document Your Learning

Ayaz — Tue, 21 Apr 2020 00:25:52 +0000

Documenting your journey can stand you out as a developer and it comes with a host of benefits both personal and professional.

A Case For Writing

Writing helps you sharpen your perception and strengthen your observation. When you are writing about what you have learned it forces you to organize your disparate thoughts into a cohesive whole which helps to clarify your own concepts.

It makes you a better thinker, a better analyst and gives you a more robust thought process system. Writing also strengthens your focus and jogs your memory. It promotes new connections among disconnected ideas and makes a web of knowledge bigger and richer.

Your writing also acts as powerful notes that you can refer back to when you want to refresh a concept and since it's written by you it is easy to understand and instantly accessible.

Writing not only helps you in cementing your knowledge but also elevates you professionally.

If you are looking to get hired, then having a portfolio of blogs (among other things) to show can give you some extra edge over other job seekers. And if you already have a job then writing can be a great tool to quickly establish you as an authority in your domain.

A Royal Road to Creativity

One very important aspect of writing is that it fosters creativity which helps your mind to fill in the gaps for missing knowledge. You learn to think out of the box, you start to ask questions, you ponder and come up with your own explanations (right or wrong).

A developer really is creator first, coder second and coding at its heart really is ingenuity wrapped in a cloak of technicality. It is a creative process that externally appears logical. So to be a better coder it makes sense to pay attention to creative development in addition to technical development.

Unfortunately, most developers never get to learn the benefit of being a creative person. They get bogged down into the rigid and restrictive mindset of what is right, what is wrong, what is fast and what is slow completely ignoring the creative side which has no boundaries, no rules and that is where great ideas and solutions are born.

So how can you activate creativity? The easiest, cheapest and most accessible way is writing. Working on the creative side helps to excel on the technical side as well.

By synching your creative (writing) and logical side (coding) you bring about a harmonious synergy in mind and create a system where one side can lean on to the other for solutions if it can't find one on its own. And having such a mental system in place makes you a better-rounded person/coder.

Get Into The Habit Of Writing

Take writing as a vital supplement to your learning. Every day, try to spend 10 minutes writing about what you have learned that day. You can begin by writing a small single paragraph about a new concept.

It doesn't have to be a fancy piece, it doesn't even have to be entirely correct. The key is not to worry too much about what you write but that you do write.

As a beginner, you may fall into the trap of comparing yourself with others in terms of quality, length, technicality, and originality. But initially, you should rather focus more on developing and refining your art.

No matter how shallow or incompetent it may sound, don't be put off by that. The goal is to cultivate the habit of writing and the quality will follow on its own. And once you become more confident, you can open up to sharing it with others.

By putting it out there you get viewpoints you haven't had the luck to explore before, it may solve an issue, refine a thought, help you see your weakness, reorient your learning and improve your understanding.

It also lends you community support and you no longer feel like operating in an isolated shell, a vital element to boost your morale.

What I Want To Write Already Exists!

You can write whatever floats your boat. But you may think oh geez there are already a dozen articles, tutorials, blogs on the same topic. Yes, there might very well be but they are not from you.

If you want to be a soap or shampoo manufacturer you wouldn't start by thinking oh my there are already a lot of soaps and shampoos on the market. Yes, there are and even though all of them pretty much do the same thing, wash your hair and body, they are not from you, they are not your product.

Similarly, when you write, don't worry about how many instances (see what I did there?) of the same topic exist, go at it anyways, marinate it nicely and spice it up with your own flavor.

You write your version of it. Just like there are many sides to the same story, there can be many authors for the same topic.

Write To Improve Not To Score Points

Remember to write for your sake first and then for others. And if in the process you build a following and people start to like you and engage with you then that is an honor and a privilege. You can be proud of that.

But if that doesn't occur it must not discourage you, because you are primarily writing to help yourself.

You are doing it because it helps you reinforce your concepts and serves as a guidepost to where you stand right now and where you ought to go.

You must not worry too much about getting likes and comments as writing is a skill and just like with any other skill it takes time to get good at it and like any other skill, it needs practice and dedication. Stick to it and you will see your efforts bloom.

Conclusion

Remember to not take writing as a chore but to have fun while doing it. Be excited when you are about to write, you don't know what your mind is going to reflect on a paper (can be electronic). Do not be dismayed by the results but be thrilled by the effort.

In due time you may become an ace writer with an audience, an independent voice, and a unique style. And then you would have yet another solid skill to flaunt apart from coding.

Be an innovator at heart and use coding to paint your art.

Concerns Of A New Developer

Ayaz — Wed, 18 Mar 2020 13:12:28 +0000

Lately, I have been seeing similar sentiments from aspiring devs who are not yet in the programming fold but want to jump aboard.

They ask certain questions and express some fears and concerns that I thought to write a post on so they might find it useful.

I now present their questions and my opinions as answers.

1) What is the hottest language going forward?

This question is inherently wrong because being a programmer is often like living in the eye of the storm where things are constantly flying around, coming into view and disappearing into the void.

You have to deal with the chaos regularly. With trends rapidly shifting, nothing is too hot for too long. The question should rather be what area do I enjoy the most.

I know a few people who caught on the React wave and decided to cash in on it. They learned React and got the job. But after a few months, they were unsatisfied, felt empty and didn't like what they were doing.

They didn't like dealing with HTML, CSS, UI interaction and other front end stuff, something was amiss, it just didn't jive with their soul.

Moreover, they also felt silly and inferior taking care of the buttons, the hover effects and the like. So ultimately they switched to the back end and quickly started finding their feet, felt much more comfortable and much happier.

So one must not see programming as having one king to rule them all. It's more like small independent sovereign kingdoms spread across the programming realm where each empire (front end, data science, hacking, gaming, distributed, backend, mobile) has its own autonomy (market/jobs), its own reigning king (the goto language) and its own politico-social setup (the community, ecosystem, backing by companies, the auxiliary tools).

These kingdoms also have relationships with each other to promote the exchange of ideas (each domain sharing its expertise, techniques, and people over with the other domain).

The kings over time can be challenged by a new contender (new trend/language/stack). Some times this disrupter succeeds in overthrowing the king (new tech is the way to go) while at other times the old king digs his heels and quells the rebel (trend dies without making any significant impact).

Some times, all the infighting fractures the kingdom and breaks it into smaller fiefdoms (multiple rulers). So you can see the programming world is as dramatic and as over the top as Game of Thrones. It is more soap opera than you had thought.

As there is no one winner, you must explore the programming world a little bit to see where you naturally fit. Going with the hottest doesn't necessarily mean you will enjoy it. Ask people around, research on the internet, watch videos and sample a few areas.

Whatever you resonate with build your home there. But later if you don't like it then don't be afraid to move on. Discovering what you like is a process and not an epiphany.

2) Is programming going to be gone tomorrow?

I hope it does, at least we all can relax for a day and finish all the side hustle that is piling on (kidding).

Are human calculations and calculators obsolete with the arrival of powerful computers? Is bicycle obsolete due to the advent of cars? You got the point.

Likewise, the programming won't be obsolete but its nature might change. But change simply reflects evolution which is natural.

Just as communication evolved from Morse Code to landlines to pager to feature phones to smartphones to foldable phones etc. We might see rapid advancement in how we do programming but it in itself will still be there.

Paradigm shifts are inescapable they are not exclusive to programming. They occur in pretty much every industry now.

So instead of discussing whether it will be over in the next few years, you should rather be asking how best I can make myself adaptable to growing changes around me and in doing so make myself more marketable.

In my opinion, soon success won't be determined by whether you have picked the winning horse from the get-go but by how quickly and masterfully you can change horses if the one you are sitting on is slowing down or is giving you a loss. That is where the winners and losers will be decided.

As the pace of technology quickens and we see more revolutions in an ever shorter time span, I feel there will be a big trend moving towards learning the adaptable mindset and how to use it effectively in your profession and your daily life.

But contrary to popular belief we can see how the evolution of technology has given rise to new fields (ML/AI, IOT, Quantum Computing, Blockchain) which were unheard of before.

And as technology continue to grow and expand even more tech-driven streams will be unlocked that we don't know yet. So, despite the doom and gloom, I see rather more opportunities than decline.

3) There are so many things to learn all the time!

Quite many coders fret over learning this or that. But you should stop looking at coding in terms of frameworks.

Coders are business people in the sense that they are laying the technological foundation on which the edifice of digital business is erected.

They are solving business problems via coding. The company that hired you or will hire you has a business problem to crack or a vision where they want to go and frameworks and languages are the tech tickets to get there.

Languages and frameworks are a means, not the end. These are simply tools even though powerful, sophisticated and at times complicated nevertheless they are but tools to address a problem and reach a goal.

Coder depression is a real thing and we are all in it together. Most of it stems from the need to learn constantly (in addition to loneliness). But if you see learning a framework as the be-all and end-all then when the new one comes out your mind flips and you get mad.

Because now there is a new moving target that you got to shoot. A mad rush to chase yet another tool. Back to square one. The frustration builds up, implodes your motivation and slumps you into your chair listlessly.

You cannot change the market trends and the direction the programming world is headed in. But you can certainly change how you frame your mind and perceive those changes. There is a nuanced psychological perception at play.

Languages and frameworks are steps to reach a goal. If you focus on the steps then when it falls out (framework/language becomes obsolete) you feel someone just pulled the rug from underneath your feet and it may rattle you emotionally.

You have to see them as tools, disposable and replaceable. And with that mindset when you keep your eyes on the goal rather than the steps, it no longer matters if the step you are standing on is completely different tomorrow.

It no longer bothers you when the new toy hits the market as getting and playing with the toy is never the goal but to use and do something with it is.

This small change in perception helps you keep your priorities straight. And you begin to think at a higher level.

You break free from the narrow thinking of framework wars and think at the level of business, creation, innovation and ponder what you can do to improve, and how you can provide greater value with the help of tech.

4) I saw this or that person, he is a genius and I feel so incompetent ergo I can't do this!

The people that you run into and get swept by can be loosely divided into two groups, fake or real.

Fake People

The inundation of media is a double-edged sword. With Facebook posts to Instagram pictures to Youtube gurus to blowhard LinkedIn profiles. Everyone wants a big title and image associated with them.

I see co-founder, entrepreneur, serial entrepreneur titles used liberally. I know some people personally who use the title entrepreneur and founder even though they haven't build a darn thing.

A lot of people just want to look and sound cool. They put on fake degrees, fake experiences, fake titles just to look competent when all they are doing is being disingenuous.

I guess having padded digital presence is a new way of saying I got a bigger car. There is a lot of wannabe influencers/experts/showman out there with some real people sprinkled here and there.

If they are pushing their image too hard chances are they are not genuine in claiming what they are. In my experience, most genuinely successful people keep it low key.

With perennial connectivity and everyone in your face every second you lose focus and start to compare yourself with every other person, you see on the internet. The result is that you feel insecure, feel defeated and give up doing even before you begin.

In my view, if anything on the internet makes u feel incompetent don't go there, turn your face away. The last thing you want to lose in today's competitive world is your self-belief and confidence.

Better alone and be stable than be with someone and have doubts about yourself. But on the other hand, if anyone inspires you, motivates you and fires you up, by all means, tag along.

Real people

In this case, you probably are comparing yourself to a person who has been around for a long time and has been in trenches. They probably have years of experience and a lot of hard work and sacrifice behind them which creates the persona you feel awed by.

The mountain you are overwhelmed with didn't come about in a day. So, this rather comes down to grind and perseverance. If you put in the same amount of work, dedication, and effort, one day you too will be feared like Mr. White (Breaking Bad).

When you are starting out don't look at how high the mountain is. Just focus on your steps one at a time.

4) I am not made for it!

When you get the gemstone from ground its never in a form to be used in jewelry. Once it's taken out it's cleansed, cut and shaped before it becomes the sparkling splendor that it does. It takes time to build your place in any field.

When you are pondering whether it's for you or not, don't treat it as a product you buy in the market, like shoes that you decide on in a few seconds. So, don't make decisions with very little understanding and with no effort put in.

Rather take some time to research and find about it as much as possible. Definitely try your hand at it, for 2 to 3 months or more if you can.

Even if you don't enjoy it initially force yourself to do it. Because often your dislike stems from your lack of understanding, your fear, and being overwhelmed by new concepts, new terms and a new way of thinking. But when you get past that phase, you begin to enjoy the field.

And if even after 3 to 4 months of trying and having given its due, you don't like it at all, by all means, you are free to move on and try something else.

Some Bonus Opinion (Double Layered Cheese)

1) Another thing to keep in mind is to not start with messy questions like Which is the best language? What are the bad sides of this or that framework? What is good, what is bad? Should I do this or that?

I call these philosophical questions. When you are starting, they are your biggest enemies and you should keep the judgemental YOU out of the picture. Just learn the trade in a systematic fashion without getting drawn into philosophical debates.

And once you are good enough then you can explore the good, the bad, the ugly and fight over it all day long.

2) Don't run after the newest shiny toy unless you really have to. If you all of a sudden see the internet coming live with talks, tutorials, forum chats, videos, blogposts, of particular language or framework, that doesn't mean you should drop everything and run after that.

My rule of thumb always is to give tech some time to mature, see how it goes and how the market reacts to it much like how you trade in stocks. And I said how the market reacts to it not the internet, there is a big difference and you should draw the line between the two.

Regardless of the internet buzz if it is not practically used by companies on a wider scale and the adoption rate is slow I would leave it for a while. Don't get caught up in the frenzy of newest and the trendiest.

On the other hand, if your company must use it or its proven to solve a problem more effectively then, by all means, jump on board. Just, don't be driven by internet hype, rather focus on things that give you immediate value.

Conclusion

Those are some of the concerns I see crop up quite a bit, so I thought to share my thoughts on it. There is no right or wrong, this is all personal opinion but you can take it as a guideline, fork these ideas into your own mind and modify them to make them work for your situation.

Rendering list items in Ruby on Rails 6

Ayaz — Thu, 14 Nov 2019 02:33:05 +0000

In web apps, we are all too familiar with the concept of looping over list items and displaying them to the user. Be it a list of products, users, articles, or some other entity.

In rails, we can display a list of items in the following ways.

1) By putting a markup of each item in a file that also contains some other markup. Basically, the item markup is not in its own separate file.

2) By putting item markup into its own separate file (partial).

In this second option, we have two convenient ways to render each item in the list.

loop over the list and pass each item as a local variable into the item partial.
pass the entire list directly to the render method.

Let's see all of it in a little more detail.

Putting item markup in a file that also contains some other markup

Imagine that we are running a men's suiting store and we have a suitings page on which we display surprisingly all the men suits via suitings.html.erb file.

<h1>Welcome to the Men's Clothing</h1>
<h2>We offer the finest men's suiting West of Atlantic</h2>
<p>While you are here paint the digital town red!</p>

<ul>
  <% @suitings.each do |suiting| %> 
    <li>
      <div><%= suiting.name %></div>
      <div><%= suiting.type %></div>
      <div><%= suiting.fabric %></div>
      <div><%= suiting.category %></div>
      <div><%= suiting.description %></div>
      <div><%= suiting.price %></div>
    </li>
  <% end %>
</ul>

<p>We hope you won't leave, without giving comfort to your body that it deserves!</p>

This is the first and the most straightforward way to display a list of items. We have @suitings instance variable coming from the controller#action. We loop over the list and display each item one by one.

Problem with this approach

Currently, the markup for each list item housed in <li> tag is only a few lines long, so it doesn't matter much.

But who is to say that our store won't become a big hit tomorrow and then we would have to render much more complicated list item markup, several lines long.

The product card may soon grow to contain checkboxes, radio buttons, drop-down, text-field, and other information about the product. Such a markup would naturally swell the list item template.

Also currently we are dumping the list item template in a suitings.html.erb file that also has its own markup, such as the <h1> <h2> and <p> tags. Perhaps this page will also grow to contain more markup.

Thus putting everything in one file can create a lot of mess and with time can become a maintenance nightmare.

That is where the second form of list items rendering comes into play, where we separate the code out into its own partial.

But before we look at that, it helps to have a little detour about the partials.

What component is to the frontend partial is to the backend.

If you have done any front-end dev with Vue, Angular or React you can think of a partial as a component.

For instance, you can have a form, header, footer, product-card, table, etc. markup littered here and there in your Rails app. They can all be converted into their own standalone partials.

These partials can be reused in multiple places very much like front-end components.

You can even design these partials to be generic so that they can respond to variables being passed in from the outside. In doing so you will be defining a public API to communicate with the partial and thus can customize it according to the context in which it is used.

We will look at a brief example of that at the end.

Having mentioned that, let's get back and look at the second way of rendering list items.

Putting Item markup in its own separate partial

Now we will create a separate partial _suiting.html.erb and put the relevant markup in there.

<li>
  <div><%= suiting.name %></div>
  <div><%= suiting.type %></div>
  <div><%= suiting.fabric %></div>
  <div><%= suiting.category %></div>
  <div><%= suiting.description %></div>
  <div><%= suiting.price %></div>
</li>

Now we can display a list of suitings in the suitings.html.erb with the following code

<ul>
  <% @suitings.each do |suiting| %>
    <%= render suiting %>       
  <% end %>
</ul>

Here, we are passing suiting as a local variable inside of the _suiting.html.erb partial.

But how does rails know which partial to use? We didn't tell that to the render method.

Rails figures that out on its own. It looks at the suiting variable and determines that it belongs to the Suiting class.

So inside of the views directory, it looks for the suitings directory, inside of that it looks for _suiting.html.erb file.views/suitings/_suiting.html.erb. Rails does that all automatically.

With that, we have a cleaner code. Now we have our suiting template housed in its own partial and if tomorrow it grows and gets complicated it won't pollute other places.

But then there is even a better and lighter syntax to render a list of items. You don't even have to define the loop construct. You can directly pass the list to the render method.

<ul>
  <%= render @suitings %>
</ul>

Here again, rails will look at each item in the @suitings list, determine that it is instantiated from the Suitings class and will look for the _suiting_html.erb partial and use that to render each item in the list.

Here the instance variable name is @suitings. But it can be any name of your choice. You can name it @men_clothes and it would work just the same because each item in the collection is still of type Suiting or instantiated from theSuiting class. So Rails would look for the _suiting_html.erb partial to render each item.

Making Suiting Partial/Component reusable

In closing, let's see how we can generalize _suiting.html.erb so that it can work with any product list such as sweaters, socks, pants and not only with suitings.

Firstly, we will rename our partial as _product.html.erb to make it more generic and make it work with any kind of product list.

Also, we will move it into a shared directory shared/_product.html.erb because now it will be shared or reused in multiple places (putting in shared directory is not required but it's a common convention).

Secondly, we will have to refactor the markup as well

<li>
  <div><%= product.name %></div>
  <div><%= product.type %></div>
  <div><%= product.fabric %></div>
  <div><%= product.category %></div>
  <div><%= product.description %></div>
  <div><%= product.price %></div>
</li>

Here we are using product as the local variable, we will see why.

Now if we want to render a list of say @shorts we can do.

<ul>
  <%= render partial: "shared/product", collection: @shorts %>      
</ul>

Here we have passed a configuration hash to the render method mentioning which list we want to render in our case @shorts using which partial in our case _product.html.erb.

Inside the partial, each list item will be available under the same name as the partial name. Since, in our case, the partial name is _product.html.erb, each item inside the partial will be called product.

Conclusion

There are three main ways to render lists inside the Rails templates.

Mixing item markup with another markup (not having its own separate file).
Creating a separate partial for item markup.
Generalizing the partial so that it can be reused in multiple places and work with any list.

A guide to creating forms in Ruby on Rails 6

Ayaz — Sun, 27 Oct 2019 18:18:40 +0000

In any app, forms serve the most primary way for data creation and modification and Ruby on Rails (from here on called Rails) app is no different.

In this guide, we will look at different ways of creating forms in Rails.

A High-Level Overview

At a high level, there are two ways of creating forms in Rails.

1) We can create the entire form by hand using HTML just as we would in any static HTML file.

2) Alternatively, we can use a powerful form_with helper that makes our lives much easier. This helper can have the following use cases.

It can be used to set up a form for a resource that is associated with an Active Record model meaning it has REST routes and also a database model. It can be both for resource creation or update.
It can be used to create a form for a resource that doesn't have any Active Record model, meaning it has REST routes but no database model.
It can be used for setting up a form having no resource and Active Record model, meaning there are neither REST routes nor any database model. Such a form can also be created by hand as point 1 illustrates but using form_with makes it easier still.

Now let's explore form creation in little more detail.

Form created with regular HTML markup

If you have done any HTML, then this one is the simplest and the most straightforward way of creating a form in Rails. Here the form is created with the usual HTML markup.

<form method="post" action="/users">
  <label for="email">Email</label>
  <input type="email" name="email" id="email">

  <label for="password">Password</label>
  <input type="password" name="password" id="password">

  <input type="submit" name="Sign up">
</form>

In such a form you define everything by yourself and don't take any help from Rails. You have to declare method="post" and set the form submission route action="/users" yourself. So far there is nothing Rails specific here.

Form Created with `form_with` method (The Rails Way)

Rails conveniently offer us a form_with method to help us in creating a form. With this method, we leverage the Rails magic.

Let's try to understand how this method works.

`form_with` in action

Suppose we have a User model with email and password attributes. If we want to create a user signup form (resource creation) this is how the form would look like.

 <%= form_with(model: @user, local: true) do |f| %>

  <%= f.label :email %>
  <%= f.email_field :email %>

  <%= f.label :password %>
  <%= f.password_field :password %>

  <%= f.submit "Sign Up" %>

<% end %>

When erb is converted to HTML through Rails asset pipeline it produces:

<form action="/users" accept-charset="UTF-8" method="post">

  <label for="user_email">Email</label>
  <input type="email" name="user[email]" id="user_email">

  <label for="user_password">Password</label>
  <input type="password" name="user[password]" id="user_password">

  <input type="submit" name="commit" value="Sign Up" data-disable-with="Sign Up">

</form>

I have skipped the input type="hidden" name="authenticity_token" tag which Rails add automatically to every form to prevent CSRF attacks.

Let's dissect the form bit by bit!

form_with is a method to which we have provided a configuration options hash. model: @user defines for which model we want to create the form. Or in other words which object will drive the form creation.

local: true configures the form submission request to be local form request. In the absence of this option, Rails configures the form to send a remote XHR request on submission.

form_with automatically sets the method="post" and the submission route action="/users". But how do Rails know which route to submit the form to and what method (HTTP Verb) to use?

Let's understand this now.

`form_with` method with `POST` request (resource creation)

If the user is signing up for the first time meaning the user doesn't exist in the database yet, then the form will be served by the User#new action in which we initialize @user = User.new.

This @user will be available in the User#new view which contains sign up form. Currently, all @user attributes are set to nil, since we didn't initialize attributes in User.new.

Thus when we set model: @user, Rails checks if any of the attributes of @user have a value other than nil. If all the fields are nil then it infers this user (resource) will be created for the first time, so it correctly sets the method="post".

But what about the route?

In order to set the route rails calls @user.class to determine the Model class name which is User, looks for a similarly named Controller class User and maps to the correct action at which the user will be created, which would be User#create for which method is POST and route is /users. And that is how it finds out where to submit this form.

If you name instance variable something else, such as @foobar = User.new and set model: @foobar it would still correctly determine the submission route by calling @foobar.class which would still be User. So instance variable name doesn't matter.

But if the Rails automatically inferred route is not where you want to submit the form, you can always use url: {whatever the submission route}. With this attribute to the form_with you have full control over the submission route, in case you need it.

`form_with` method with `PATCH` request (resource update)

The second case is where you are creating a user edit form. Here when you click a particular user link that needs an edit, the request will be mapped to User#edit where you will fetch the user as @user = User.find(params[:id]). This @user will be available in the User#edit view.

But since this time @user attributes have values, rails prepopulate corresponding form fields with available values taking care of not populating password field, so it filters that out.

Also because @user attributes have values (even if one attribute has a value other than nil) rails infers that it is not a new resource meaning you are not creating it for the first time but instead you are looking to modify an existing resource.

So it sets up the route properly by again calling the @user.class to determine Model, find its namesake Controller User and map to User#update which deals with updating a user, having the route users/:id with a PATCH request.

But, there is a problem the browser doesn't natively support the PATCH request it only supports POST AND GET.

Rails achieve that by inserting the following tag inside of the form

<input type="hidden" name="_method" value="patch">

How does that work?

POST simply allows the browser to send data to the server. Form submission piggybacks that to transport data to the server but after the data is transferred it needs to tell Rails that it's not a POST data but a PATCH data and it accomplishes that by using such an input tag.

It simply acts as a label to tell Rails that it's a patch request and use incoming data as an edit data, not a creation data.

When such a request hits the Rails app, it looks at the form find the hidden input field with a value="patch" and routes it to the User#update which handles PATCH request. So a lot of work is done by Rails.

Let's take some other intricacies about the form_with method

Form submitting to itself (GET and POST route are the same)

If you create a random instance variable such as @have_no_class that has no associated Model. So when Rails try to determine the submission route it calls @have_no_class.class it gets NilClass and since it couldn't correctly infer the submission route for this resource it would set the route to itself.

So if you landed on the page with GET request to '/signup' then it would submit the form to itself at '/signup' with POST. Unless the Rails did actually determine the route and it turned out to be the same as the GET route.

form_with gives a FormBuilder object

form_with takes an options hash but it also takes a block and passes a FormBuilder object as a block variable.

<%= form_with(model: @user, local: true) do |f| %>

|f| is the FormBuilder object (you can name it anything you want) that helps us in setting up form fields. It has methods for creating all the form elements such as radio button, text-area, check-box, input etc.

So if you want to create an input of type=password you would do

<%= f.label :password %>
<%= f.password_field :password %>

It will produce

<label for="user_password">Password</label>
<input type="password" name="user[password]" id="user_password">

Here we gave :password symbol as an argument to the f.label method which it uses to set up the label text and for="user_password". for is set to user_password and not password because we set model: @user so it prefixes it with the name of the model.

Similarly in the input tag for password, it sets the id="password", type="password" and name="user[password]". In order to understand user[password] we have to look at the params hash.

A look at the `Params` hash

You have to be mindful of the fact the Rails use the params hash for sending any data that is being transferred with the request, be it dynamic URL segment like /:id or query param like ?page=1 or the data sent via POST or PATCH request, all are available inside the params hash. In simple words params contain some information about the incoming request.

What Rails does is that it sets up user hash inside of the params hash and inside the user hash it sets up all the form name, value pairs.

When the form is submitted it takes all the form values, stuffs them in the user hash of the params hash and sends it to the server.

params: {
  user: {
    email: 'foobar@baz.com',
    password: 'foobar'
  }
}

That is why you see the name="user[password]" because it is setting up the password field on the user hash and setting its value to whatever is typed into the field. But this is all done behind the scenes by Rails.

Now coming back to the FormBuilder object |f|.

You can additionally set up any other attribute on input password tag (or any other form field) by passing in the options hash such as setting up the class attribute.

<%= f.password_field :password, class: 'form-control' %>

FormBuilder object, in our case |f| has convenient methods to which you pass configurations and it produces the desired form element for you.

`form_with` method for a non-model resource

form_with can also be used to set up a form for a resource that has no Model. It means it has some or all of the REST routes but no Model to persist the data. A classic example would be creating Session as a REST resource but with no Model, because data is sent to the browser and not stored on the server.

In such a form creation you don't say model: @session because there is no Model to instantiate the object which can be passed into view. Instead, we use scope: 'session'. This does all the Rails magic steps as discussed earlier.

Before we have been using model attribute now we use scope. We use model when we have the Model whose instance is going to drive the creation of the form.

With Session since we don't have a Model we don't use model attribute. Instead, we use scope that sets up the session hash inside of params hash and all the form values will be stuffed inside of the session hash.

Since this time we don't have an instance variable to determine the class and the route, the form submits to itself (same route it is served from).

Key Takeaways

If you have a form to either create or update a resource that happens to have an associated Model as well, use from_with and set model: {whatever the instance varaible}.
If you have a form for a resource that does not have an associated Model, use from_with and set scope: {whatever the scope name you want in params hash}.
If you want to create a non-resource form, you can do so with a form_with in which case you would have to define url: '{whatever form submission route}'. Or you can create the form by hand, the good-ol way.

Forem: Ayaz

Document Your Learning

A Case For Writing

A Royal Road to Creativity

Get Into The Habit Of Writing

What I Want To Write Already Exists!

Write To Improve Not To Score Points

Conclusion

Concerns Of A New Developer

1) What is the hottest language going forward?

2) Is programming going to be gone tomorrow?

3) There are so many things to learn all the time!

4) I saw this or that person, he is a genius and I feel so incompetent ergo I can't do this!

Fake People

Real people

4) I am not made for it!

Some Bonus Opinion (Double Layered Cheese)

Conclusion

Rendering list items in Ruby on Rails 6

Putting item markup in a file that also contains some other markup

Problem with this approach

What component is to the frontend partial is to the backend.

Putting Item markup in its own separate partial

Making Suiting Partial/Component reusable

Conclusion

A guide to creating forms in Ruby on Rails 6

A High-Level Overview

Form created with regular HTML markup

Form Created with form_with method (The Rails Way)

form_with in action

form_with method with POST request (resource creation)

form_with method with PATCH request (resource update)

Form submitting to itself (GET and POST route are the same)

form_with gives a FormBuilder object

A look at the Params hash

form_with method for a non-model resource

Key Takeaways

Form Created with `form_with` method (The Rails Way)

`form_with` in action

`form_with` method with `POST` request (resource creation)

`form_with` method with `PATCH` request (resource update)

A look at the `Params` hash

`form_with` method for a non-model resource