DEV Community: Austin J. (github.com/jufudev)

What is mindsync©️?

Austin J. (github.com/jufudev) — Fri, 09 Jun 2023 22:12:13 +0000

mindsync©️ is officially open-source

Which technically still applies when there is essentially... no... source... uhhh..

☝️ I'll be working on that for at least ~10 hours per week until it feels like it's so good that I don't need to anymore, or it's so trash that I should delete it... ;)

💡 I have broad ideas to chase down around UI/UX, MVP, features, free/paid lines of demarcation, etc. I've got some product designing to do before we get into the code. I aim to keep this pretty light... I'd much rather get something out to folks ASAP and hear what they have to say before trying to see 12 moves ahead of the chessboard.

I don't know if this thing will ever make a dime. I'm starting from a place of building something that I wish existed. Maybe there's more people out there that can benefit from it.

Of course, like an impatient 12 year old, as all engineers can be, I've already selected the tech stack. These are technologies that I've worked with before that I am sure can accomplish the task at hand in a manner that doesn't bloat the app or make me want to pull my non-existent hair out.

Surprise! All of the tools/frameworks I'm using are open-source too.

	Responsibility	Technology
👨‍💻	UI	React Native
🌤️	Client state	Context API
☁	API/Server	.NET
❓	Unified Querying	GraphQL
🔌	GraphQL Server for .NET	Hot Chocolate
📀	Database	Neo4j
🔌	Neo4j/.NET ORM	Blueprint41
🔥	DevOps	GitHub

I'm trying to decide if it's worth it to write infrastructure as code for this project... it sounds fun, at least.

💭 Why so Gung ho on open-source? What is this app? Why is this the 58th post you've made about it before writing one line of code? wtf is mindsync? Let me explain.

🧠 mindsync will be a mobile household/family/private-shared productivity, planning, and task scheduling/reminding/notating app with strong focuses on ease of use, user engagement/personalization, security, and neurodiversity. An open-source license is paramount for this kind of application, in my opinion, because I want you to love the design, love how the app helps you and your family remember and accomplish tasks, and be able to 100% trust that you can enjoy your experience without worrying about your data.

Period.

The concept is:
✅ secure
✅ focused
✅ practical
✅ intuitive
✅ way too easy to use

I want to fundamentally change the way families/households/friend groups communicate the never-ending list of household tasks, events, to-do lists, and other pertinent planning information with one another; especially for folks of neurodiversity, i.e. ADHD, General Anxiety, ASD, etc. I want to do it in a way that acknowledges...

👉 Verbal communication and physical logging/remembering of tasks or events is just a recipe for disaster for so many of us. In my experience, it is hard to express why I cannot remember a single thing that I do not write down and make a reminder for. This niche has solutions already, for sure, but...

❗️ They just kinda suck.

Every. Single. F*cking. One. Google Drive, Microsoft 365, doesn't matter.

🗑️ Other solutions are too clunky. The principal users who have formed a sharing group and attempt to share things with each other are not regarded as the central domain -- You and your family/friends should be the focus! It's your data, your experience!

🥷 Other solutions don't give a sh*t about your data privacy or digital safety. This one is just plain obvious. Apple and Google have both been caught multiple times divulging information about their users they weren't supposed to.

💰 Other solutions cost way too much. The last time I tried to open a shared Microsoft 365 "organization", the price was bottom-lined at what a company of 100 people would pay. How does that make sense?

❌ It doesn't. None of it makes any sense. They all suck at everything they strive to do when it comes to the household-range of users.

😕 These huge services weren't built with your challenges in mind. They were not built to ease the lives of groups of 2-10 people with powerful, focused, personalized tools like mindsync will be.

❓ When is the last time Google Drive suggested a change in your schedule to you? When is the last time Microsoft 365 noticed other users haven't viewed your Calendar event yet and notified you?

🛸 That's right... never.

🤝 Simply Put:

❌ I will never require the entry of or store your full legal name.

❌ I will never ask you to generate a short, insecure password; 256 characters permitted.

❌ I will never require or collect your phone number. You won't have to delete 78 authentication codes per month. You won't have to worry about my little app adding to your random spam-call misery.

❌ I will never require you to write loathsome, generic security questions and answers.

❌ 99.9% of integration logins will not be allowed.

🚦 The only integration I will allow is Apple, if it is required in the App store.

✅ You will only provide a name of your choice (not my business), an email address you can rely on, and a password.

✅ You will only use 3rd party authentication apps or email when you're having access trouble.

✅ You will be surprised and impressed by the app's performance. Large companies break the rules of separation of concerns to ship software faster. I don't do that.

⚠️ This is crucial: this app will not be intended for use with folks you do not know or trust. You should never interface with someone you do not know through mindsync.

🔍 And therein lie the differences

between mindsync and the massive platforms Microsoft, Google, Apple, and others have tried to shoehorn together based on their massive data-mining systems to accomplish the goal of digital shared planning of events, tasks, appointments, grocery lists, files, etc...

👾 My app will be singularly built for this purpose. My app will allow you to see exactly what I am doing with your data, as it is open-source. Heck, before version 1.0, I'll even publish a human-readable report on the lifecycle of each piece of PII that I ask you for; and then your smart hacker friend can double check anytime in my source code. I'll make sure the report stays up to date with the app.

💯

I cannot guarantee you a FAANG closed-source OS you are using will never grab and sell your data anyway, but I can guarantee you my application will not be the culprit. If this is ever false, I will always revert the version and remove the issue from public use immediately and make sure it is fixed before we re-visit that new version.

This is the largest... thing... in general that I have ever taken on by myself. Yeah I know; I'm not the first dope to open-source an application. It is truly important to me, and I want in some small way to show you why it should be important to you, too.

I want to build something that I can use at home with my family. To have an easy, personalized experience that learns more about my relationship with menial tasks, scheduled events, note-taking, and sharing frequency everyday, and offers me a better experience with that information. Most importantly, I want you to have this tool, as well, and help me make it better for all of us.

I've got a long road ahead. I am optimistically planning for exclusive beta testing by the end of this year. There will be plenty of updates as initiatives progress. Thanks for reading 👍

How a Deep Dive into TypeScript Impacted My Job Search

Austin J. (github.com/jufudev) — Fri, 08 Oct 2021 18:35:10 +0000

Spoiler: TypeScript isn't the only thing TypeScript taught me.

If you're a boot camper like me, you may know that most coding boot camps teach more functional programming than anything. You may also know languages that strongly favor functional patterns are the roots of the skills taught at boot camps. This includes languages like JavaScript (JS) and Python. What is the problem with this?

JavaScript and Python are implicitly-typed languages

At least Python's type-safe rating is "strong." JS's type-safe rating is "weak." Let's talk about JS. JavaScript has been the most-loved and the most-hated programming language all at once for quite some time now. A lot of the hate for JavaScript is due to its absence of a strict typing system. Where a language such as Java will crucify you for a null check, JavaScript says, "A string divided by a string? Yeah, that might work. Let's run it."

For noobs, that's great! Experienced developers with exposure to type systems and object-oriented programming (OOP) are not likely to be big fans of JS, though. They'll likely spend some time scratching their heads when working in JS. Many believe that typing systems should be introduced to juniors as early as possible. I agree after learning TypeScript (TS).

In an implicitly-typed language, a variable's type is implied by its definition and other mutations. However, the variable is not restricted to its original implied type. Further, unless you have a special linter checking things like this, you will not know about error-bound operations until they happen. JavaScript fixed a little bit of this with the const keyword in ES6. It's not nearly enough, however. In JavaScript, an object's properties can still change to any type you like. This gets very dangerous in large code-bases. At best, it can require a ton of comments and developer focus to ensure something is never changed or coerced to a type that will not work with the operations working on that variable. The worst-case scenario, of course, is production coming down.

The decision to learn TS

After my boot camp concluded, I had trouble deciding what to learn next. I thought about GraphQL, Shopify, a deep dive into Node, and many others. Each of these seemed either too big or too small to help me in the job search. I wanted something that would teach me more about computer science; something widely used with deep roots in the computer science world. I settled on TypeScript because it can be used anywhere JavaScript is. I hope that you will consider learning TS after reading this post.

What did I learn?

Everything. Er... well, everything about strict typing. I thought TypeScript might be missing some things in comparison to the strict typing systems in Java or C#. I did not find that to be the case. Here is what surprised me... I found the more I learned about TypeScript, the more I learned about typing systems in general. Eventually, I became committed to typing every reference and variable I possibly could in my projects. This saved me a lot of debugging in the long run. Documenting the shape of your models and using said shapes to prevent errors in one fell swoop is empowering. Experienced OOP developers are reading this like, "Um... yeah. That's the point. It's called an interface." Right you are! Interfaces and classes are the heart and soul of what makes TypeScript valuable for you as a Junior JavaScript Developer.

What did it do for my job search?

It made me a better interviewee and a more attractive candidate. Not only did I have another popular technology under my belt, but I was able to approach interview coding challenges in strictly-typed languages with a lot more confidence. While in the job search, I had to complete a take-home challenge in Java. Now, I'd had a little bit of experience in Java, but never anything like my experience in JavaScript. Meaning, I didn't write an API or desktop application or anything like that in Java. So, I was reasonably concerned with my ability to do well on a Java coding challenge.

Once I began the challenge and started researching how to implement my solution, I was pleasantly surprised by how much TypeScript is transferrable to Java! It makes perfect sense when I think about it now, however. TypeScript is maintained by Microsoft and is meant to function a lot like the typing system of C#: their alternative to Java. I handled strict-typing with ease even though I'd never done anything half as advanced as this challenge with Java. When I came across a type error in this challenge, I knew where to look each time. If I had not committed to learning TS, I would not have been ready for this interview challenge.

TypeScript is the best next thing to learn for a junior

I did well with that challenge. I attribute a lot of my success in that situation to the fact that I decided to start using TS in all of my JS endeavors about two months before. If you are a boot camp graduate or a Junior JavaScript Developer looking to learn something that will vastly broaden your coding horizons, learn TypeScript.

As a bonus, you will finally understand all of the JavaScript hate when you see how much chaos pure JavaScript allows compared to TypeScript.

If anything in this article is inaccurate or misleading, please do not hesitate to reach out so I can change it! I am still a junior myself, and I want to learn as much as possible.

Using Context and Custom Hooks to Manage a Toggle Menu

Austin J. (github.com/jufudev) — Sat, 26 Jun 2021 01:25:36 +0000

My solution to closing a toggle menu at times that it makes sense for the user experience.

I set out to a build a new, beautiful portfolio site after graduating from my bootcamp. I knew that I didn't want to use any template sites to just get it done quickly - I wanted to build something authentic with React. I encountered a few hiccups along the way. One of them was managing whether or not my navigation menu would be open upon certain user-generated events. Here's how I managed to close my menu without the user clicking it directly.

STEP 1: Creating states and passing them through context.

// track clicks that should close the menu, but don't
const [clickEvent, setClickEvent, clickEventRef] = useState(false);

// state to track whether the menu is open or not
const [menuIsOpen, setMenuIsOpen] = useState(false);

// define a context object with the states you need
const context = { 
    clickEvent,
    setClickEvent,
    clickEventRef,
    menuIsOpen,
    setMenuIsOpen,
};

Using the useStateRef package, I make two new states. One to track click events that should close the menu, but are not direct clicks on the toggle button itself. The other simply tracks whether the menu is open or not. The clickEvent state will be used like a toggle flip-flop.

STEP 2: Provide the context to the routes.

// in a file called context.js, create context object with createContext hook.
import { createContext } from "react";
export const MenuContext = createContext(null);

/* import that context object where you will be wrapping your routes 
in the context. here's what mine looks like in that file.
*/

import { MenuContext } from "../util/context.js";

/* now you will wrap the routes in the context provider. make sure
the context definition containing your states is defined in
the same file as your routes
*/ 

const context = { 
    clickEvent,
    setClickEvent,
    clickEventRef,
    menuIsOpen,
    setMenuIsOpen,
};

return (
    <MenuContext.provider value={context}>
        <Header />
        <Routes />
        <Footer />
    </MenuContext.provider>
);

If you've never used context or the createContext hook before, think of the MenuContext.provider tag as a container that gives the components inside access to the value attribute. Since the context and the routes are in the same tag, the routes have access to the context.

Cool! Now we've provided the context (the states) to our entire application. This is usually not ideal, but in this case, it's fine :D

STEP 3: Use the useContext hook to use the state values.

The first place I needed to import these states and affect them is in my header component. You will need to import useContext and the actual context instance made with create context in context.js anywhere that you need to do this.

// your import statements may look different but here's mine
import React, {useEffect, useContext, useRef, useState} from "react";
import { MenuContext } from "../utils/context";

export default function Header() {
    // "tell" react you want the context in the MenuContext.provider
    const context = useContext(MenuContext)
    ...
}

First, since the menuIsOpen state is supposed to track whether the menu is open or not, I put this functionality in.

<Navbar.Toggle
    onClick={(_) => context.setMenuIsOpen((prev) => !prev)}
    ...
/>

Now the state will be representative of the menu... let's try to keep it that way moving on! This turned out to be easier said than done...

STEP 4: Closing the menu upon some other click... but how?

What to do next took me a little bit of time to figure out... I knew that I needed to close the menu without the user clicking the menu button itself for intuition's sake, but how? This is where useRef came in handy.

const toggleHamburger = useRef();

// in the return statement, same toggle from earlier
<Navbar.Toggle ref={toggleHamburger} ... />

At this point, React has a reference to affect this element. Now upon some other event the user generates in which we want the menu to close, we can have React click this button for us! For me, a good reason to close the menu was if the user clicks one of the options in it. Like this:

How do you do this?

You can write a handleClick function. But this might get repetitive, as the goal is to be able to close this menu upon some event across the application. We will want to be able to export/import this functionality in some way. What if we build a custom hook?

// here is the custom hook I built in a file simply named useClickSideEffect.js
export const useClickSideEffect = ({
  clickEvent,
  setClickEvent,
  clickEventRef,
  setMenuIsOpen,
}) =>
  () => {
    setClickEvent(() => !clickEvent);
    setMenuIsOpen(() => clickEventRef);
  };
}

clickEventRef makes sure that we have the most current state of clickEvent after a recent change. I believe it is necessary to develop with useStateRef or something like it when you encounter a situation where you must use a state for some other programmatic task immediately after an update.

Side note: State updates are not asynchronous. However, the instantaneous, infinitesimal, yet briefly large, immediately decaying delta in client-side load caused by a newly queued re-render causes processes to slow briefly; enough to cause a race-condition between line 15 that updates the state and line 16 that needs it to be current... yeah, the difference is that small. But big enough. React re-renders cause the DOM to briefly forget, reread, and rebuild itself with JavaScript's instructions... So, be careful describing any state updates as asynchronous. Even though they can appear to be, they are not. This problem heavily depends upon the size of your application, the version of React you are running, and the client-host. Nonetheless, I say useStateRef and others like it are so easy to plug in that there is no point in taking this chance.

STEP 5: Using the custom hook.

When we use the hook, we will have to provide it the props it wants. That should be easy. We already have the context in the routes!

// in Header
import React, { useEffect, useContext, useRef, useState } from "react";
import { MenuContext } from "../utils/context";
import { useClickSideEffect } from "../util/useClickSideEffect";

export default function Header() {
    const context = useContext(MenuContext);
    const handleSideClick = useSideClick(context);
    ...
}

Alright... now, we've made a custom hook that returns a function that changes the clickEvent and menuIsOpen states. We have grabbed an instance of that function. Now we have to call that function upon clicks on the nav links and have a useEffect that reacts to a change in clickEvent's state.

export default function Header() {

    // handleSideClick changes clickEvent, so the useEffect will catch this change.
    useEffect(handleClickSideEffect, [context.clickEvent]);
    function handleClickSideEffect() {

        // we don't want it to toggle if it is already closed
        if (context.menuIsOpen) {
            // click the toggle button using current toggleHamburger ref we made earlier
            toggleHamburger.current.click();

            /* reflect the change to the menu in its state. we can be explicit
            and set it to false since we know we are closing it.
            */
            context.setMenuIsOpen(() => false);
        }
    }

    return (
        ...
        <Nav.Link onClick={handleSideClick}>Home</Nav.Link>
        ...
    );
}

Voila. Now, our toggle menu closes upon one of its nav links being clicked. Awesome!

Of course, since we made this a custom hook, we can import it and use it anywhere that has the same context. Another time I use it in my portfolio site is if either button on the contact page is clicked. Essentially, I want the menu to close any time the route changes. Both of these buttons change the route.

You are more than welcome to view my source code if you need more context ;) ... about what is going on here in these code snippets!

You can always contact me via LinkedIn or at jufudev@proton.me as well.