Compromeez 3.0 released with adding WhatsApp support and multi-line address

I just released Compromeez 2.0 a few days ago and I got some interesting ideas based on the company profile project I'm currently working on.

It's not much, but since it has breaking changes, I want to talk about it individually.

WhatsApp support

In the company profile I'm working on, the client needs to show that they can be reached from both phone call and sending a message to WhatsApp. Most people here prefer to communicate using WhatsApp so it is a reasonable request.

Phone number and WhatsApp number have different format and different use case. It is common to see a button when clicked will open WhatsApp to send the message directly.

To solve this problem, I add WhatsApp number column on manage company page so you, the developers, can get the WhatsApp number from page props.

const page = usePage()

const { whatsapp } = page.props.company

Of course, you can change it to other messaging service that use mobile phone number to communicate like Telegram.

Multiline address

Previously, I used a single-line address and store it as a string data type on the table column.

Some country, like in Indonesia, use multi-line text to show the company address. So, to address this issue, I decided to switch from using text input to text area to input the address and use text data type for the table column.

Now, you can just copy-paste the address and it will showed nicely on the page.

Breaking changes

Since this update changed the structure of the company table, you will need to reset your database by using Artisan migrate command.

php artisan migrate:refresh --seed

About database migration

Why I didn't use database migration when adding or changing table columns? Maybe some of you have been wondering about it and I just remembered about it.

At first, I assume we will always use the latest Compromeez on our new project. So, I thought that creating migration just to add one or two columns or changed the column type is not necessary. I thought that it is better to just changed the table column and run migrate:refresh that recreate the tables.

Now, I'm thinking that if database migration always recreate and apply changes chronologically, then it is not too bad to hide the changes, right?

I'm going to think about this and I'd greatly appreciate any thoughts, ideas, and other point of views. I'd love to hear from you in the comments!

LinkedIn

Assalaamu 'alaikum 👋

Saya Findra. Selamat datang di blog saya. Di sini, saya berbagi panduan seputar Debian, pengembangan aplikasi web, serta berbagi catatan pribadi.

Saya berharap blog ini bisa jadi sumber daya yang bermanfaat dan menumbuhkan semangat belajar kita bersama, terutama dalam ekosistem Linux dan teknologi web.

Semoga bermanfaat!