TILs - Fueling Curiosity, One Insight at a Time

In Flutter, widgets are the building blocks of your UI (similar to components in React), and there are mainly 3 type of widgets based on how they handle state: Stateless, Stateful, and Inherited widgets

Stateless Widgets:
- Stateless widgets are immutable i.e. their configuration cannot change once they are created. They represent parts of your UI that don't depend on any mutable state.
- Stateless widgets rebuild when their parent widget or the widget hierarchy above them rebuilds and when an Inherited widget it depends on changes

Stateful Widgets:
- Stateful widgets are mutable and holds some internal state that can change over time. They are used when a part of your UI depends on dynamic data or user interactions.
- Stateful widgets rebuild when their internal state changes. State updates are handled using setState() which also triggers a rebuild of the widget and its subtree. They can also rebuild when their parent widget or the widget hierarchy above them rebuilds.

Inherited Widgets:
- Inherited widgets are a special type of widget used to share data or state across an entire widget subtree without having to pass the data explicitly to every widget in the subtree (concept of Inherited widget is similar to Context API in React)
- Whenever the value inside Inherited widget changes, the widgets dependent on this widget get rebuilt.

Difference between dynamic and Object type in dart
dynamic : dynamic is incredibly flexible. It tells Dart compiler to skip the type checking at compile time while type checking happens at run time. This is helpful when working with data of uncertain types.





Object : Object is the root class for all other classes. Its like a container like that can hold any value. Since Object is generic, you won't have access to specific methods or properties of value without type casting

When running a javascript/typescript file during build time that requires environment variables importing dotenv config gets the job done. Alternate approach is to have values in package.json that goes against the idea of having the environment variables as secrets and hidden from the repository code.

In a web application, there can be scenarios where certain data needs to be fetched conditionally. For eg, in application with multiple user roles, there might be a specific role for which certain data is not needed. In such a case, we might want to avoid making unnecessary API calls to fetch that data. However, due to React's rules of hooks, we cannot directly conditionally call a hook which fetches data.

If you're using a library like react-query and if you do not want to create a wrapper component to fetch the data, react-query provides a good solution. react-query has an enabled option for its useQuery hook. We can conditionally enable or disable the query based on our needs.




Here the useQuery is only executed if isAuthenticated is true. If isAuthenticated is false, the query is skipped.

Use environmental variables in flutter

- Install flutter_dotenv package
- Create a .env file in the root of your project
- Add your variables to the .env file
- In order for the package to load .env file, add it to asset bundle in pubspec.yaml




- Load the contents of env into flutter, by adding this is main.dart



- Access the env variable like this dotenv.env['APP_ENVIRONMENT']

below are the generator helper methods used to perform various actions in files and directories
• copy_file
• create_file
• insert_into_file
• inside
• gsub_file

generate generator by doing bin/rails generate generator initializer .
This will create the below files for you

Slack apps best practices and User experience - https://api.slack.com/best-practices

How we can Set up Puma as Systemd service in Ubuntu 18 for Rails application, The main purpose is ,
• to ensure it starts automatically on boot,
• can be managed easily with systemd's service management commands,
• It also allows for better process management, automatic restarts in case of failure, and logging capabilities,
• few set of commands used to create puma.service file and getting it started:
for file creation : /etc/systemd/system/puma.service
sudo systemctl daemon-reload
sudo systemctl enable puma
sudo service puma start
sudo service puma status

Retrieving Command History with FZF
Command: To view the command history, we can use the following command:
history | fzf
Note: Ensure that you have FZF installed before. It provides an efficient way to navigate through past commands.