Javascript

How to Contribute to Redwood.JS

Feb 1, 2022

3 min read

This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel.

In our first episode, I sat down with David Price one of the creators and maintainers of RedwoodJS! If you would like to watch this interview, you can find it here!

What is RedwoodJS?

RedwoodJS is an app framework built on React, Prisma, and GraphQL that is especially useful for startups interested in prototyping since it integrates everything someone would need to carry out fullstack development out of the box. These integrations include Storybook, Webpack/Babel, and more with zero configurations.

The goal of RedwoodJS is, in part, to allow developers to focus on what makes their applications unique and interesting by handling a lot of the configuration logic inherent to deploying fullstack applications.

David Price

David Price is the Founder of human(Ethos), a San Francisco-based consulting firm that helps product teams build cultures of performance, and currently works as a Developer in Residence at Preston-Warner Ventures. Beyond this, David is one of the Creators of Redwood.JS, and serves as a Maintainer.

Important Resources to Check Out Before Contributing

If you would like to learn more about the specific features offered by RedwoodJS, you can read up on the official documentation here.

You can check out the RedwoodJS repository here. David suggests that new users spend time in the packages folder since these are all the packages that will get published to npm.

And finally, if you would like to become engaged with other developers interested in RedwoodJS, you can join the official community server and/or the official discord server.

The Best Way to Get Started

Before contributing any code to RedwoodJS’ open-source repository, David Price suggests introducing yourself to and getting support from the larger RedwoodJS community using some of the resources above:

“The way to get started is to get the moral support in the community, and say you are interested in helping out! And they can direct you!”

Not only will that give new contributors an idea of what current projects are in the works and where they can help, but it can help them connect with other developers who will direct them to the most ability-appropriate tasks.

PRO-TIP from David: There is a file in the repo itself, called contributing.md, that shows you how to get started on actual contributions!

New contributors can also click on the “help wanted” tab in Github issues to see what work is needed, and available! There are also tags called “good first issue”, which are great entry points to the project. Another tag is “bug/confirmed”, which allows contributors to help with bugs!

Great at reviewing code? Code reviews support functional testing in the PRs! Inside of the CI checks, there is a link to Gitpod which will pull up a VScode virtual editor that creates a test project. You can use this to help run tests! Anyone can come into a PR, run a test, and go through the process to report back what worked and didn't work.

Attending RedwoodJS Contributor Meetups

Visit the community forums for RedwoodJS to learn more about how the community is structured. As mentioned above, there are a number of useful discussion boards where you can find information about announcements, docs, and opportunities to contribute. Once you are active on the forums, you will be eligible to receive invitations to private contributor meetups, but be sure to ask for one, since there may not be Core Contributors who are actively searching for folks to invite!

Contributor Success Stories

Peter Colapietro started opening and contributing to PRs for Hacktoberfest. Because of his consistent, high quality work since October, he now helps with the Storybook team, working on a really important PR!
There are collaborators working with diversity outreach for Redwood.JS, and they have been brainstorming a lot of ideas on how to get people involved! Multiple contributors have landed jobs after working with RedwoodJS. The community has been growing and evolving. Jobs are being created within the community.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Tracy Lee

Partner, This Dot Google Developer Expert (Angular, TC39, Web) RxJS Core Team & Lead for RxJS Learning Team Contributor to Angular, RxJS, EmberJS

Key Strengths:

Teaching developer relations strategies
Influencer marketing
Developing brands
Community strategies and maintenance
Creating product launch strategies
Leading marketing operations efforts & standards
Effective conference presence & speaking strategies

@ladyleet @ladyleet

Understanding Vue.js's <Suspense> and Async Components

In this blog post, we will delve into how and async components work, their benefits, and practical implementation strategies to make your Vue.js applications more efficient and user-friendly. Without further ado, let’s get started! Suspense Let's kick off by explaining what Suspense components are. They are a new component that helps manage how your application handles components that need to await for some async resource to resolve, like fetching data from a server, waiting for images to load, or any other task that might take some time to complete before they can be properly rendered. Imagine you're building a web page that needs to load data from a server, and you have 2 components that fetch the data you need as they will show different things. Typically, you might see a loading spinner or a skeleton while the data is being fetched. Suspense components make it easier to handle these scenarios. Instead of manually managing loading states and error messages for each component that needs to fetch data, Suspense components let you wrap all these components together. Inside this wrapper, you can define: 1. What to show while the data is loading (like a loading spinner). 2. The actual content that should be displayed once the data is successfully fetched. This way, Vue Suspense simplifies the process of handling asynchronous operations (like data fetching) and improves the user (and the developer) experience by providing a more seamless and integrated way to show loading states and handle errors. There are two types of async dependencies that can wait on: - Components with an async setup() hook. This includes components using with top-level await expressions. *Note: These can only be used within a component.* - Async Components. Async components Vue's asynchronous components are like a smart loading system for your web app. Imagine your app as a big puzzle. Normally, you'd put together all the pieces at once, which can take time. But what if some pieces aren't needed right away? Asynchronous components help with this. Here's how they work: - Load Only What's Needed: Just like only picking up puzzle pieces you need right now, asynchronous components let your app load only the parts that are immediately necessary. Other parts can be loaded later, as needed. - Faster Start: Your app starts up faster because it doesn't have to load everything at once. It's like quickly starting with the border of a puzzle and filling in the rest later. - Save Resources: It uses your web resources (like internet data) more wisely, only grabbing what’s essential when it's essential. In short, asynchronous components make your app quicker to start and more efficient, improving the overall experience for your users. Example: ` Combining Async Components and Suspense Let's explore how combining asynchronous components with Vue's Suspense feature can enhance your application. When asynchronous components are used with Vue's Suspense, they form a powerful combination. The key point is that async components are "suspensable" by default. This means they can be easily integrated with Suspense to improve how your app handles loading and rendering components. When used together, you can do the following things: - Centralized Loading and Error Handling: With Suspense, you don't have to handle loading and error states individually for each async component. Instead, you can define a single loading indicator or error message within the Suspense component. This unified approach simplifies your code and ensures consistency across different parts of your app. - Flexible and Clean Code Structure: By combining async components with Suspense, your code becomes more organized and easier to maintain. An asynchronous component has the flexibility to operate independently of Suspense's oversight. By setting suspensible: false in its options, the component takes charge of its own loading behavior. This means that instead of relying on Suspense to manage when it appears, the component itself dictates its loading state and presentation. This option is particularly useful for components that have specific loading logic or visuals they need to maintain, separate from the broader Suspense-driven loading strategy in the application. In practice, this combo allows you to create a user interface that feels responsive and cohesive. Users see a well-timed loading indicator while the necessary components are being fetched, and if something goes wrong, a single, well-crafted error message is displayed. It's like ensuring that the entire puzzle is either revealed in its completed form or not at all rather than showing disjointed parts at different times. How it works When a component inside the boundary is waiting for something asynchronous, shows fallback content. This fallback content can be anything you choose, such as a loading spinner or a message indicating that data is being loaded. Example Usage Let’s use a simple example: In the visual example provided, imagine we have two Vue components: one showcasing a selected Pokémon, Eevee, and a carousel showcasing a variety of other Pokémon. Both components are designed to fetch data asynchronously. Without , while the data is being fetched, we would typically see two separate loading indicators: one for the Eevee Pokemon that is selected and another for the carousel. This can make the page look disjointed and be a less-than-ideal user experience. We could display a single, cohesive loading indicator by wrapping both components inside a boundary. This unified loading state would persist until all the data for both components—the single Pokémon display and the carousel—has been fetched and is ready to be rendered. Here's how you might structure the code for such a scenario: ` Here, is the component that's performing asynchronous operations. While loading, the text 'Loading...' is displayed to the user. Great! But what about when things don't go as planned and an error occurs? Currently, Vue's doesn't directly handle errors within its boundary. However, there's a neat workaround. You can use the onErrorCaptured() hook in the parent component of to catch and manage errors. Here's how it works: ` If we run this code, and let’s say that we had an error selecting our Pokemon, this is how it is going to display to the user: The error message is specifically tied to the component where the issue occurred, ensuring that it's the only part of your application that shows an error notification. Meanwhile, the rest of your components will continue to operate and display as intended, maintaining the overall user experience without widespread disruption. This targeted error handling keeps the application's functionality intact while indicating where the problem lies. Conclusion stands out as a formidable feature in Vue.js, transforming the management of asynchronous operations into a more streamlined and user-centric process. It not only elevates the user experience by ensuring smoother interactions during data loading phases but also enhances code maintainability and application performance. I hope you found this blog post enlightening and that it adds value to your Vue.js projects. As always, happy coding and continue to explore the vast possibilities Vue.js offers to make your applications more efficient and engaging!...

Apr 24, 2024

6 mins

VueWeb PerformanceUXJavaScript

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Although Developer Relations (DevRel) defies traditional marketing strategies, prioritizing enhancing developer satisfaction ahead of promoting numbers that contribute to a sales funnel, it is still possible for DevRel teams to fail at delivering desired business objectives. And unfortunately, more often than not, this leads to the dissolution of DevRel efforts, and sometimes even role elimination. Below, I’ve compiled a list of five of the top reasons why DevRel teams fail. 1. Lack of Leadership Buy-In DevRel requires buy-in and support from executives and stakeholders within the company. Without buy-in, being able to work cross-functionally across the organization, get access to data needed for measuring success, have the ability to influence change within the organization, or get the budget for necessary activities to engage developers will be impossible. I asked Jason Lengstorf, the host and founder of Learn With Jason and previously on the Developer Relations team at Netlify and Gatsby, where he has seen companies fail at DevRel before: “Companies that want to invest in DevRel can collect as many well-known developers as they can, but giving them zero dollars and zero autonomy will force teams to rage quit or become content farms because that’s all you can do with no budget.” Other examples are departments not willing to share or give data that helps enable DevRel to understand the metrics they need to effectively baseline and track the success of their efforts. By not doing so, the DevRel team will not be able to justify their work to leadership, which will lead to those positions being cut first when budget cuts come around. Chris Woodruff, Founder of Advocatus, a Developer Relations consultancy, says “DevRel is seeing a lot of layoffs. It’s the easiest team for management to let go because they don’t fully understand the ROI and metrics. These are the holy grails of DevRel, and because they do not understand, they will always be the first teams to let go if management can’t see the actual return or how it affects the bottom line.” 2. Company Culture Fit If an organization's culture does not value collaboration and resists the presence of a DevRel team, DevRel will not be able to effectively advocate for developers or help teams be more successful with their target audience. Francesco Tisiot, Senior Developer Advocate at Aiven, an open-source data platform that makes setting up cloud databases simple, shared one of his experiences in his Developer Relations career. “I was one of the first DevRel hires in a company and we were in the marketing organization. Initially, there was pushback from engineering and product teams on our product feedback and feature requests since we weren't seen as experts. But, DevRel is about breaking barriers and building bridges, so, in leading by example, we demonstrated our technical knowledge and now have a strong impact on all the teams.” Michael Liendo, Senior Developer Advocate at AWS, an online platform by Amazon that provides scalable and cost-effective cloud computing solutions, shared how he was able to find the company culture fit within organizations he has served in the past. Being in a position of Developer Advocacy, and quite literally trying to advocate for developers that use the platform, he says, “Some of the biggest challenges for DevRel are actually internal. Engineers at many companies often focus on one piece of the product. As they're testing features, they may be creating workarounds without realizing they're workarounds. This means they often miss what a proper Developer Experience flow looks like. I've had to push for them to include me in design meetings, and get them to understand that I'm the Lorax--I speak for the community! A phrase I have been known to say is ‘this solves the problem, but it's not a solution’. I'm known for having a high bar for what is considered ‘good enough’ and though the end result is accumulated trust, it's a challenge to get there.” 3. Operating in Isolation DevRel cannot operate in isolation without integration with development, marketing, product teams, sales, or a subset of these. The team will struggle to make a significant impact. DevRel requires a collaborative approach and alignment and synergy with other teams. Francesco Ciulla, Developer Advocate at daily.dev, a professional network for developers that provides the latest tech news and articles, shares his thoughts on how DevRel organizations can be successful within larger organizations: “DevRel organizations can thrive within larger organizations by establishing clear communication channels and fostering meaningful collaborations. They must align their objectives with the company's goals and illustrate their value by sharing tangible outcomes from developer engagement.” 4. Lack of Strategy Proceeding into DevRel without a clear strategy will make it difficult for a DevRel team to establish its purpose within an organization and set priorities that will make an impact. There will not be a clear vision the team can drive towards, leading to wasted efforts and the inability to produce tangible outcomes. If DevRel does not have any goals set, they can only do their best to assume what efforts they should invest in to provide value to the organization. Worst yet, if they do not have any goals set, they may not choose to focus on providing value to the organization, but to a community that the organization has no interest in. Many DevRel experts have seen this happen time and time again in the community, and are always left scratching our heads. Many times, the “strategy” for an organization is to hire DevRel, but that is where the strategy stops. Decision-makers want DevRel professionals to come in and just “do what they do best”. Unfortunately, when decision-makers say this, they typically have an idea of what outcomes they want DevRel to drive, but don’t want to share those thoughts because they feel like DevRel professionals should know what to do. Expectations left open to interpretation often lead to a poor impression of the performance of the DevRel team by decision-makers, and those teams are never able to establish a sense of trust or direction within that organization. Jeremy Meiss, former Director of Developer Relations at CircleCI, says, “One of the biggest problems we have seen in this industry is the startups that were counseled by their VC, founders, or board that they need a DevRel team because the other similar companies had one and it was great for them. They push for it, and one of the early hires is DevRel. Generally, that DevRel hire is someone relatively new in the industry, so you can coax them to start at a new company without clear goals or objectives. New hires like this come in without a lot of experience in the field of DevRel and have not experienced it at different levels of companies. They are heavily pushed by marketing, the CEO, the CTO, and other departments into thinking DevRel should look a certain way, but don’t have the foundational knowledge to be able to push back because they are not yet in this area.” Jeremy’s illustrative explanation of why a lack of strategy ultimately results in the failure of a DevRel team within an organization is one that is common across many devtool startups that have popped up in recent years. 5. Lack of Metrics and Reporting A well-rounded set of DevRel metrics typically comes from multiple areas of the organization, whether that be marketing, sales, product, customer success, or customer support. Without free access to cross-functional team data, it is difficult to show the value and ROI of DevRel. Establishing a baseline set of metrics if you’re new within an organization, or understanding the baseline metrics that currently exist is critical in ensuring the success of your job in DevRel. Tessa Mero, Head of Developer Relations at Appwrite, has a very specific set of metrics her team focuses on. She shared a few of those metrics: - Growth of our GitHub Repo (stars) - Growth of our Discord Community - Improved engagement in Discord community - Growth of our Twitter followers and engagement - Growth of our Appwrite Cloud developers - Number of views or impressions on any video and written content, whether it's internal or externally created - Amount of content created weekly (written or video) - Number of projects created with Appwrite for Hackathon sponsorships - Number of attendees / questions at a conference talk - Number of connections at conferences - Number of community support questions answered, improving rate of responses AND rate of how fast we respond, in all public forums - Number of support tickets responded to - Number of community feedback taken and moved into our DX/Product discussions - Number of feedback from UI/UX perspectives and working with design team to follow up with the devs/users with what we did with the feedback - Number of engagement/activity from our Appwrite heroes/ambassadors This is just one example of and a subset of metrics a DevRel team should consider tracking, but what you track and how you track it is dependent on your goals and the product. Metrics and what your leadership considers a good ROI can vary greatly from organization to organization. I spoke to another Developer Relations expert in the industry and she shared her experience with the company she just left and the reason she left - and it was focused around metrics. She was initially interested in joining the team because of the lack of metrics. However, over time, as she got more experience and as she became more visible, her workload became difficult to prioritize. Since there were no metrics, there were no objectives to measure against to say what was good and what was bad. She felt like she didn’t know what she was doing well or not doing well. Once metrics began to be implemented, the company started pushing her to do more, and she had nothing to push back with because the high-level goals were not there. There was no way to prioritize the workload. The company started tracking things like page hits, unique visitors, unique views of videos, number of subscribers, activity on twitter, and other similar numbers, but it was hard to tie any of these back to the ROI for the company. How do you quantify and determine if 100 new subscribers on YouTube is better than 100 new subscribers on twitter? If you can’t quantify it, how do you prioritize it? What Successful DevRel Teams Do Differently With the nature of DevRel and the multitude of levers and factors that determine success and failure, it’s important to allow space for a team or set of individuals to experiment and iterate before making judgment calls. One company that serves millions of developers on its platform is starting up a new meetup program and testing the ROI of sponsoring meetups around the world. Since they are in the testing and experimentation phase, they don’t yet know how to measure success, and that is clear to leadership. The current strategy is sponsoring local meetups for a few months and seeing what the result is. Why are they so seemingly laid back in their approach? Is it the right approach? The reason for the relaxed nature of the testing phase is that they don’t want to be pushy to the meetup organizer to find something out or measure something. They are not expecting anything, but will evaluate what metrics they could use to establish success criteria. This approach is a thoughtful and empathetic one, and clearly, the DevRel team has an understanding of how to approach community members in a way that will not turn them off. Internally, the simple numbers they are looking at are the number of RSVPs, the number of attendees that show up, and the difference between the two. DevRel is naturally iterative and requires a team to experiment, test, and refine their strategies. Effectively engaging developers is not black and white, and a strategy that works for one community or company may not necessarily work for another. Furthermore, building domain expertise and gaining a deep understanding of the developer community they serve takes time. Experimentation and iteration help teams refine their knowledge, identify patterns, and develop strategies that resonate with developers. This expertise becomes an asset in driving long-term success. It’s also important to acknowledge that building domain expertise within a segment as well as building relationships and trust with developers in that segment takes time. The technology landscape changes quickly and new technologies are being released weekly. Developer sentiment is fickle and changes just as quickly regarding favored approaches and products. That being said, the above pitfalls remain common causes for DevRel teams to fail, and by remaining mindful of and vigilant against them, DevRel teams both new and old can succeed in supporting key business objectives like developer retention, community growth, and product development....

Feb 14, 2024

9 mins

DevRel

Transforming Auth in an AI World with Rod Boothby

In today's digital landscape, the need for secure identity verification has become paramount. With the increasing risks of personal data exposure and the rise of sophisticated cyber threats aided by Artificial Intelligence, it is crucial to adopt robust verification processes to protect individuals and organizations alike. In a recent discussion with Rod Boothby, CEO of ID Partner Systems, the significance of trusted institutions for identity verification was emphasized, particularly the efficiency of bank-based ID verification over traditional methods. One of the key takeaways from the conversation was the importance of continuous authentication. As technology advances, so do the methods employed by cybercriminals. Deepfake technology, for instance, poses a significant threat to identity verification systems. To combat this, tighter security measures and continuous authentication are essential. By constantly verifying and validating user identities, organizations can stay one step ahead of potential fraudsters. Rod Boothby also highlighted the need for a developer-focused approach to identity verification. By providing developers with the tools and resources they need, companies like ID Partner Systems aim to streamline the verification process and enhance security. This approach not only ensures a more efficient experience for users but also allows for the integration of behavioral biometrics, which can further strengthen the verification process. Download this episode here....

Apr 22, 2024

1 min

Engineering Leadership

How to Contribute to Redwood.JS

Tracy Lee

You might also like

Understanding Vue.js's <Suspense> and Async Components

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Transforming Auth in an AI World with Rod Boothby

You might also like

Understanding Vue.js's <Suspense> and Async Components

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Transforming Auth in an AI World with Rod Boothby