10, 2024 (GLOBE NEWSWIRE) — Digital Element, a global leader in IP intelligence and geolocation solutions, today announced that its threat intelligence platform, Nodify, has received a 2024 CyberSecurity Breakthrough Award in the category of Threat Detection Solution Provider of the…

Digital Element’s Nodify Named Threat Detection Solution Provider of the Year from CyberSecurity Breakthrough Awards

Element

element

Swift’s structured concurrency has transformed the way we write asynchronous code. With async/await, expressing complex logic becomes cleaner and more linear. However, to fully leverage Swift’s concurrency, you need a solid grasp of how tasks are created and managed — particularly Task, .task, and their variations. Task .task Task: Entering an Async Context from Sync Code Task The most direct way to launch asynchronous code from synchronous code in Swift is with Task. Task Task {
    let profile = try await userService.fetchUserProfile()
    print("Name:", profile.name)
} Task {
    let profile = try await userService.fetchUserProfile()
    print("Name:", profile.name)
} This creates a concurrent task that begins executing immediately. Inside, you can call async functions, use try, and handle cancellation. You can also store the task in a variable to cancel or await its result later: concurrent task async try let task1 = Task {
    try await userService.fetchUserProfile()
}
try await task1.value

let task2 = Task {
    try await userService.fetchUserProfile()
}
task2.cancel() let task1 = Task {
    try await userService.fetchUserProfile()
}
try await task1.value

let task2 = Task {
    try await userService.fetchUserProfile()
}
task2.cancel() Tasks created this way inherit the actor context they are declared in — commonly MainActor when used in the UI. MainActor .task: Async Work in SwiftUI Views .task In SwiftUI, the idiomatic way to launch asynchronous work when a view appears is using the .task view modifier: .task Text("Loading...")
    .task {
        await userService.fetchUserProfile()
    } Text("Loading...")
    .task {
        await userService.fetchUserProfile()
    } This modifier starts a structured task that is tied to the view’s lifecycle, ensuring it is automatically cancelled when the view disappears or when its state changes. When the .task(id:) value changes, it cancels the previous task and starts a new one. However, cancellation only sends a signal — it doesn’t guarantee the task will actually stop unless the code inside is cancellation-aware. .task(id:) Cancellation Awareness Swift’s concurrency model is cancellation-aware. When SwiftUI cancels a .task, or when you cancel a task manually using task.cancel(), that doesn't magically stop your code. The task is marked as cancelled, but cancellation only takes effect when your code checks for it or uses suspending calls that throw CancellationError. So, cancellation is cooperative — your task must opt in to it. .task task.cancel() marked CancellationError cancellation is cooperative Here's an example where cancellation works as expected: .task {
    do {
        try await Task.sleep(for: .seconds(1))
        print("1 second passed")
    } catch is CancellationError {
        print("Sleep was cancelled")
    } catch let error {
        print("Error: \(error)")
    }
} .task {
    do {
        try await Task.sleep(for: .seconds(1))
        print("1 second passed")
    } catch is CancellationError {
        print("Sleep was cancelled")
    } catch let error {
        print("Error: \(error)")
    }
} If you're working with async code that doesn’t throw, you can check Task.isCancelled manually: Task.isCancelled .task {
    await performSomeWork()

    if Task.isCancelled {
        return  // Exit early if no longer needed
    }

    await performMoreWork()
} .task {
    await performSomeWork()

    if Task.isCancelled {
        return  // Exit early if no longer needed
    }

    await performMoreWork()
} Using withTaskCancellationHandler withTaskCancellationHandler When you need to perform immediate cleanup or handle cancellation in long-running operations, withTaskCancellationHandler gives you precise control. withTaskCancellationHandler Here’s a complete example: func fetchData() async throws {
    try await withTaskCancellationHandler(
        operation: {
            print("🔄 Starting data fetch...")
            try await Task.sleep(for: .seconds(3))
            print("✅ Data fetched successfully!")
        },
        onCancel: {
            print("🛑 Task was cancelled. Cleaning up resources.")
        }
    )
}

// Launch the cancellable task
let task = Task {
    try await fetchData()
}

// Simulate cancellation after 1 second
Task {
    try await Task.sleep(for: .seconds(1))
    task.cancel()
} func fetchData() async throws {
    try await withTaskCancellationHandler(
        operation: {
            print("🔄 Starting data fetch...")
            try await Task.sleep(for: .seconds(3))
            print("✅ Data fetched successfully!")
        },
        onCancel: {
            print("🛑 Task was cancelled. Cleaning up resources.")
        }
    )
}

// Launch the cancellable task
let task = Task {
    try await fetchData()
}

// Simulate cancellation after 1 second
Task {
    try await Task.sleep(for: .seconds(1))
    task.cancel()
} 💡 What’s happening here: The first task begins a simulated long-running operation.
After 1 second, the second task cancels the first one.
The onCancel closure runs immediately when the task is cancelled, even if the inner operation is still ongoing. The first task begins a simulated long-running operation. After 1 second, the second task cancels the first one. The onCancel closure runs immediately when the task is cancelled, even if the inner operation is still ongoing. onCancel This is a precise, predictable way to control task cancellation beyond just try await + catch. try await catch Task Priorities You can assign explicit priorities to tasks using either Task(priority:) for manual tasks, or .task(priority:) when working in SwiftUI: Task(priority:) .task(priority:) Task(priority: .background) {
    await userService.fetchUserProfile()
}

.task(priority: .background) {
    await userService.fetchUserProfile()
} Task(priority: .background) {
    await userService.fetchUserProfile()
}

.task(priority: .background) {
    await userService.fetchUserProfile()
} Priorities such as .userInitiated, .background, .utility, etc. serve as scheduling hints to help the system prioritize execution under load. However, they do not affect the thread or actor context where the task runs. For example, a .task(priority: .background) launched from a SwiftUI view still runs on the MainActor unless explicitly detached. If you need true background isolation, you must use Task.detached(...). .userInitiated .background .utility .task(priority: .background) Task.detached(...) .task(priority:) vs Task.detached(priority:) .task(priority:) Task.detached(priority:) There’s a critical distinction: .task(priority: .background) {
    let profile = await userService.fetchUserProfile()
    name = profile.name
} .task(priority: .background) {
    let profile = await userService.fetchUserProfile()
    name = profile.name
} This task still runs within SwiftUI’s MainActor context. It is safe to access @State, @Environment, or any UI-bound data. MainActor @State @Environment In contrast: Task.detached(priority: .background) {
    let profile = await userService.fetchUserProfile()
    await MainActor.run {
        name = profile.name
    }
} Task.detached(priority: .background) {
    let profile = await userService.fetchUserProfile()
    await MainActor.run {
        name = profile.name
    }
} Task.detached creates a task that does not inherit the current actor or task-local values. Task.detached not It is designed for truly independent background work. Using it improperly inside SwiftUI may cause UI updates from the wrong thread. Awaiting Task Results with .value .value You can create a task and later await its result explicitly: let task = Task {
    return try await userService.fetchUserProfile()
}

do {
    let profile = try await task.value
    print("Name:", profile.name)
} catch {
    print("Error:", error)
} let task = Task {
    return try await userService.fetchUserProfile()
}

do {
    let profile = try await task.value
    print("Name:", profile.name)
} catch {
    print("Error:", error)
} This gives you control over when the task is awaited — useful for coordination or deferring work. Common Pitfalls Swift’s concurrency is powerful, but there are a few subtle traps developers often fall into. Below are common mistakes to watch out for when working with Task and .task in real-world code. Task .task Ignoring Cancellation with try? try? This is a typical example where cancellation seems to work — but doesn't seems .task {
    try? await Task.sleep(for: .seconds(1))
    print("Still printed")
} .task {
    try? await Task.sleep(for: .seconds(1))
    print("Still printed")
} Here, the task is cancellable in theory — Task.sleep throws on cancellation — but try? suppresses the error, including CancellationError. So even if the view disappears or the task is explicitly cancelled, the error is swallowed, and the remaining code continues to execute. This makes the task look cancellable, but it won’t actually stop when it should. Always prefer do/catch over try? when cancellation matters. This makes the task look cancellable, but it won’t actually stop when it should. Always prefer do/catch over try? when cancellation matters. do/catch try? Ignoring Errors in Task This compiles: Task {
    try await userService.fetchUserProfile()
} Task {
    try await userService.fetchUserProfile()
} But if fetchUserProfile() throws, the error is ignored. The task silently fails, which can be misleading or dangerous. Always handle errors explicitly: fetchUserProfile() Task {
    do {
        try await userService.fetchUserProfile()
    } catch {
        print("Failed:", error)
    }
} Task {
    do {
        try await userService.fetchUserProfile()
    } catch {
        print("Failed:", error)
    }
} Misunderstanding Task Priority Setting a task’s priority, like .task(priority: .background), does not move the task to a background thread or actor. If launched inside a SwiftUI view, it still runs on the MainActor, unless explicitly detached. .task(priority: .background) not MainActor This is a common misconception. If you need true isolation from the UI thread, use Task.detached — and don’t forget to switch back to MainActor if you update the UI. Task.detached MainActor Conclusion Task and .task are powerful building blocks for structured, safe, and cancellable concurrency in Swift. When used properly: Task .task Use .task for view-bound async work.
Use Task {} for imperative async calls.
Use Task.detached when you truly need to isolate work from your current context.
Always handle cancellation and errors explicitly.
Use withTaskCancellationHandler when you need precise control over cleanup logic and cancelling task.
Remember that task priority is just a scheduling hint, not a thread/context control. Use .task for view-bound async work. .task Use Task {} for imperative async calls. Task {} Use Task.detached when you truly need to isolate work from your current context. Task.detached Always handle cancellation and errors explicitly. Use withTaskCancellationHandler when you need precise control over cleanup logic and cancelling task. withTaskCancellationHandler Remember that task priority is just a scheduling hint, not a thread/context control. And of course — this is far from everything you can do with Task. Its capabilities go much deeper: child tasks, task groups, task-local values, cooperative cancellation, custom executors, and more. I encourage you to experiment, read the official documentation, and explore concurrency beyond the surface level. Task official documentation

Mastering Swift Structured Concurrency: Dive into Task and Asynchronous/Await

Enhance Your Code Architecture With SOLID Principles (with Swift Examples)

Building a UDP Server & Client in Swift with Network.framework

As AI becomes more advanced and capable, it’s being applied to a growing number of use cases. There are more and more instances of AI being used as a tool by software developers and the recent emergence of ‘vibe coding’ has certainly been grabbing a lot of media attention. Just a few months ago, Andrej Karpathy coined this term to describe the process of asking LLMs such as ChatGPT and Claude to write code by giving it simple, natural language instructions. While this approach is capable of generating working code, it's not yet able to produce advanced software programs unassisted – not yet anyway. But LLMs are being used as tools by developers as they build software intended for real-world use cases. Andrej Karpathy Andrej Karpathy are being used are being used The key here is that even though the LLMs are writing the code, the people commanding it to do so are still capable of understanding what's been written. If they couldn't, then debugging, maintaining and securing the codebase effectively would be impossible. AI is an assistant that is being used to make suggestions, rather than provide answers that can be trusted 100%. Like in other parts of software development, human oversight still plays an important role. It's especially vital for humans to be involved in the testing of usability and accessibility in software – but it’s also critical that humans remain the master of all software testing processes. LLMs can write code – but are poor usability testers LLMs can write code – but are poor usability testers LLMs have been trained on the vast reams of data, images and text from a magnitude of sources around the internet and are designed to behave in an expected manner when carrying out tasks such as writing an email, for example. They’ve been trained to code by ingesting simple programs written by human software engineers. And LLMs have also been trained to understand imperfect input. They’re designed to try and understand the user at all times, so they will attempt to fill in the gaps when the user skips words or doesn’t express themselves clearly. And this ‘understand at all costs’ approach is in conflict with the idea of usability testing. Usability testing requires developers to switch their focus to specific frames of reference where they ask if the behaviour of software is clear, or work with a focus group to establish that the product is intuitively usable. LLMs are not well-positioned to test for any flaws in usability as they are trained to understand everything – for them, there’s no difference between bad and good. But for human users, usability is judged in terms of whether software works in line with their preconceptions, which are often based on previous experience. You can’t ask the humans to re-learn their approach to using software – the program has to meet their expectations. Even if software comes with documentation, you can’t rely on users to read these instructions. That’s why a significant part of usability testing is making sure that software behaves with an implied knowledge of how things should work. should Accessibility testing requires human oversight Accessibility testing requires human oversight Poor accessibility is something that impacts many different groups of people — not just those with permanent disabilities. It also includes temporary impairments (like a broken arm) and situational ones (like bright sunlight or background noise). These concepts, popularized by Microsoft’s Inclusive Design work in the mid-2010s, show that accessibility isn’t just about edge cases — it’s about building software that works for everyone, in any context. Currently, LLMs are unlikely to have been trained to recognise poor colour contrast that could affect users with visual impairments – because they are trained to understand everything, they will see every pixel as perfect. Nor will they pick up issues with bad keyboard navigation, text with poor readability and a lack of zoom functionality. However, it is entirely possible to train models to check for accessibility issues and offer advice to developers. But LLMs could only ever provide assistance in these scenarios – human oversight would be necessary to understand what accessibility aspects we are looking to address. AI cannot manage risk or be held accountable AI cannot manage risk or be held accountable With large, complex software applications, systematic testing is necessary prior to release. However, exhaustive testing isn't possible – there are just too many potential use cases and inputs that the application could encounter. That means decisions have to be made about what to test – and what tests don't need to be carried out. This is a vital part of QA – and it cannot be left to AI. QA teams must draw on their experience, knowledge, and judgement to make informed decisions. They must plan, prioritize and make risk assessments. They will understand that there are trade-offs that need to be made – but they can make accountable decisions and justify them to relevant stakeholders. If AI makes these decisions, then there's no accountability if something goes wrong. Where AI  can streamline software testing and test management Where AI  can streamline software testing and test management There are many areas of the software testing process where AI can be of assistance. There’s a lot of heavy lifting involved in software testing such as preparing test data, suggesting the specific scenarios that need to be tested, and writing automated tests. AI agents are already capable of performing some basic tests today, and it’s likely they’ll take on even more complex testing tasks in the near future. And AI also has utility for software test management. It can be used to help with writing test documentation, and to suggest ideas for key areas to test. It can be used to research other, similar software projects to surface relevant data and insights that could assist the testing. And it can also perform data analysis of the test results, creating reports for relevant stakeholders quickly so they don't have to wait for human operatives to compile their reports. Humans are the end users – so human expertise is needed Humans are the end users – so human expertise is needed Quality in software is non-negotiable. We’ve all heard stories about disastrous software launches where products have been shipped with massive issues that have made them completely unusable for a certain group of people. For now, usability and accessibility are human domains so it is natural to use humans for testing these aspects. In the era of AI, it's important to maintain human oversight. If AI is used in software creation, testing or test management it is vital to check the results. QA teams need to be the ones that take accountability for software test management processes. Only they have the domain knowledge and understanding of business priorities to determine test coverage and acceptable levels of risk. While AI can support these processes with data and recommendations, it cannot currently make business critical decisions on its own.

The Human Testing Element is Still Important Despite Advances in AI 

Do you know that feeling when you create your own component instead of improving the default HTML components? Your design team created something beautiful, but browsers won't support it out of the box, and fixing it everywhere becomes a nightmare. We all know this pain, but these challenges make our job interesting. Today, I wanted to talk about one pitfall that awaits us during this thrilling journey: the placement of dropdown elements, such as the select menus or the date pickers. Absolutely Wrong At first, it looks like position: absolute solves all our problems, and it does to some extent. But then, modal windows ruin everything. If the dropdown overflows, it gets cut off. Sure, you can scroll down and see it, but you’d better pray that your designer cannot reach you with a sharp object. That’s far from perfect—we can do better. Fix It With 'fixed' If we want to display the content over everything, we need position: fixed. The only problem is that we will lose the parent element coordinates: fixed elements are quite independent by nature. This means the only thing we need to do is determine the exact coordinates of the drop-down element in these situations: When we display it.
When its content is changed.
When we scroll the window and/or the scrollable parent.
When we resize the window and/or the scrollable parent. We also need to decide whether to display it above the toggler if it is too close to the bottom of the screen. Feels doable. I will use Vue.js, but it should be easy to follow even if you prefer React or Angular. Let’s Rock This Joint Here’s the structure we’ll use: export const useDropdownAttributes = () => {
  const dropdownWidth = ref('');
  const dropdownTop = ref('');
  const dropdownBottom = ref('');
  const dropdownLeft = ref('');
  const isDirectedUpwards = ref(false);
  const togglerRect = ref<DOMRect>();
  const dropdownRect = ref<DOMRect>();

  const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLDivElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    // ...
  }

  return {
    autodetectPosition,
    dropdownTop,
    dropdownBottom,
    dropdownLeft,
    dropdownWidth,
    isDirectedUpwards,
    togglerRect,
    dropdownRect,
  };
}; There are four variables for the dropdown position plus the isDirectedUpwards flag and a function that updates them all. We also return two variables for the toggler’s and dropdown’s Rects: this might be convenient, for example, for the tooltips that need to be aligned to the middle of the content. As you may remember, we also need to handle the scrolling and resizing of the scrollable parent, so let’s create a function to find it: const getFirstScrollableParent = (element: HTMLElement | null): HTMLElement => {
    const parentElement = element?.parentElement;
    if (!parentElement) return document.body;

    const overflowY = window.getComputedStyle(parentElement).overflowY;

    if (overflowY === 'scroll' || overflowY === 'auto') return parentElement;

    return getFirstScrollableParent(parentElement);
  }; Now, let’s add the main function: const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    if (!togglerElement || !dropdownElement) return;

    const updateDropdownAttributes = () => {
      togglerRect.value = togglerElement.getBoundingClientRect();
      dropdownRect.value = dropdownElement.getBoundingClientRect();
      dropdownWidth.value = `${togglerRect.value.width}px`;
      dropdownBottom.value = `${window.innerHeight - togglerRect.value.top}px`;
      dropdownTop.value = `${
        window.innerHeight - togglerRect.value.bottom - dropdownRect.value.height
      }px`;
      dropdownLeft.value = `${togglerRect.value.left}px`;
    };

    const handleResize = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    const handleScroll = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    watch(
      [isDropdownDisplayed, dropdownContent],
      ([newVal, _]) => {
        const scrollableParent = getFirstScrollableParent(togglerElement);
        if (!newVal) {
          window.removeEventListener('resize', handleResize);
          window.removeEventListener('scroll', handleScroll);
          scrollableParent.removeEventListener('resize', handleResize);
          scrollableParent.removeEventListener('scroll', handleScroll);
          return;
        }

        requestAnimationFrame(() => {
          const distanceFromBottom =
            window.innerHeight - togglerElement.getBoundingClientRect().bottom;
          const distanceFromTop = togglerElement.getBoundingClientRect().top;
          const dropdownHeight = dropdownElement.offsetHeight;

          isDirectedUpwards.value = isUpwardPreferred
            ? distanceFromTop > dropdownHeight
            : distanceFromBottom < dropdownHeight &&
              distanceFromTop > dropdownHeight;

          updateDropdownAttributes();
          window.addEventListener('resize', handleResize);
          window.addEventListener('scroll', handleScroll);
          scrollableParent.addEventListener('resize', handleResize);
          scrollableParent.addEventListener('scroll', handleScroll);
        });
      },
      { deep: true },
    );
  }; We pass isDropdownDisplayed and dropdownContent so we can react to their updates. We also pass togglerElement and dropdownElementwhich we need to calculate the position. Finally, there’s isUpwardPreferred in case you want the dropdown above the toggler by default. Time to Relax and Enjoy In your component, you will need something like this (I assume you have added refs to your toggler and dropdown in the template): const {
  autodetectPosition,
  dropdownTop,
  dropdownBottom,
  dropdownLeft,
  dropdownWidth,
  isDirectedUpwards,
} = useDropdownAttributes();

const togglerRef = ref<HTMLElement>();
const dropdownRef = ref<HTMLElement>();

const isDropdownShown = ref(false);

onMounted(() => {
  autodetectPosition(isDropdownShown, togglerRef.value?.$el, dropdownRef.value?.$el);
}); And the CSS will look like this: .dropdown {
  position: fixed;
  bottom: v-bind('isDirectedUpwards ? dropdownBottom : dropdownTop');
  left: v-bind('dropdownLeft');

  width: v-bind('dropdownWidth');
  min-width: 0;
} Voilà. The dropdown is displayed properly even when overflowing and moves above the toggler if there isn’t enough space below. And since we’re at the end of the article, I’d love to leave you with something cheerful—but I’m out of ideas. So, I'm afraid "good luck" is all I have this time. Good luck. 👋 You can find the complete code on GitHub. Do you know that feeling when you create your own component instead of improving the default HTML components? Your design team created something beautiful, but browsers won't support it out of the box, and fixing it everywhere becomes a nightmare. We all know this pain, but these challenges make our job interesting. Today, I wanted to talk about one pitfall that awaits us during this thrilling journey: the placement of dropdown elements, such as the select menus or the date pickers. Absolutely Wrong At first, it looks like position: absolute solves all our problems, and it does to some extent. But then, modal windows ruin everything. position: absolute If the dropdown overflows, it gets cut off. Sure, you can scroll down and see it, but you’d better pray that your designer cannot reach you with a sharp object. That’s far from perfect—we can do better. Fix It With 'fixed' 'fixed' If we want to display the content over everything, we need position: fixed . The only problem is that we will lose the parent element coordinates: fixed elements are quite independent by nature. This means the only thing we need to do is determine the exact coordinates of the drop-down element in these situations: position: fixed When we display it. When its content is changed. When we scroll the window and/or the scrollable parent. When we resize the window and/or the scrollable parent. When we display it. When its content is changed. When we scroll the window and/or the scrollable parent. When we resize the window and/or the scrollable parent. We also need to decide whether to display it above the toggler if it is too close to the bottom of the screen. Feels doable. I will use Vue.js, but it should be easy to follow even if you prefer React or Angular. Let’s Rock This Joint Here’s the structure we’ll use: export const useDropdownAttributes = () => {
  const dropdownWidth = ref('');
  const dropdownTop = ref('');
  const dropdownBottom = ref('');
  const dropdownLeft = ref('');
  const isDirectedUpwards = ref(false);
  const togglerRect = ref<DOMRect>();
  const dropdownRect = ref<DOMRect>();

  const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLDivElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    // ...
  }

  return {
    autodetectPosition,
    dropdownTop,
    dropdownBottom,
    dropdownLeft,
    dropdownWidth,
    isDirectedUpwards,
    togglerRect,
    dropdownRect,
  };
}; export const useDropdownAttributes = () => {
  const dropdownWidth = ref('');
  const dropdownTop = ref('');
  const dropdownBottom = ref('');
  const dropdownLeft = ref('');
  const isDirectedUpwards = ref(false);
  const togglerRect = ref<DOMRect>();
  const dropdownRect = ref<DOMRect>();

  const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLDivElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    // ...
  }

  return {
    autodetectPosition,
    dropdownTop,
    dropdownBottom,
    dropdownLeft,
    dropdownWidth,
    isDirectedUpwards,
    togglerRect,
    dropdownRect,
  };
}; There are four variables for the dropdown position plus the isDirectedUpwards flag and a function that updates them all. We also return two variables for the toggler’s and dropdown’s Rects: this might be convenient, for example, for the tooltips that need to be aligned to the middle of the content. isDirectedUpwards As you may remember, we also need to handle the scrolling and resizing of the scrollable parent, so let’s create a function to find it: const getFirstScrollableParent = (element: HTMLElement | null): HTMLElement => {
    const parentElement = element?.parentElement;
    if (!parentElement) return document.body;

    const overflowY = window.getComputedStyle(parentElement).overflowY;

    if (overflowY === 'scroll' || overflowY === 'auto') return parentElement;

    return getFirstScrollableParent(parentElement);
  }; const getFirstScrollableParent = (element: HTMLElement | null): HTMLElement => {
    const parentElement = element?.parentElement;
    if (!parentElement) return document.body;

    const overflowY = window.getComputedStyle(parentElement).overflowY;

    if (overflowY === 'scroll' || overflowY === 'auto') return parentElement;

    return getFirstScrollableParent(parentElement);
  }; Now, let’s add the main function: const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    if (!togglerElement || !dropdownElement) return;

    const updateDropdownAttributes = () => {
      togglerRect.value = togglerElement.getBoundingClientRect();
      dropdownRect.value = dropdownElement.getBoundingClientRect();
      dropdownWidth.value = `${togglerRect.value.width}px`;
      dropdownBottom.value = `${window.innerHeight - togglerRect.value.top}px`;
      dropdownTop.value = `${
        window.innerHeight - togglerRect.value.bottom - dropdownRect.value.height
      }px`;
      dropdownLeft.value = `${togglerRect.value.left}px`;
    };

    const handleResize = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    const handleScroll = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    watch(
      [isDropdownDisplayed, dropdownContent],
      ([newVal, _]) => {
        const scrollableParent = getFirstScrollableParent(togglerElement);
        if (!newVal) {
          window.removeEventListener('resize', handleResize);
          window.removeEventListener('scroll', handleScroll);
          scrollableParent.removeEventListener('resize', handleResize);
          scrollableParent.removeEventListener('scroll', handleScroll);
          return;
        }

        requestAnimationFrame(() => {
          const distanceFromBottom =
            window.innerHeight - togglerElement.getBoundingClientRect().bottom;
          const distanceFromTop = togglerElement.getBoundingClientRect().top;
          const dropdownHeight = dropdownElement.offsetHeight;

          isDirectedUpwards.value = isUpwardPreferred
            ? distanceFromTop > dropdownHeight
            : distanceFromBottom < dropdownHeight &&
              distanceFromTop > dropdownHeight;

          updateDropdownAttributes();
          window.addEventListener('resize', handleResize);
          window.addEventListener('scroll', handleScroll);
          scrollableParent.addEventListener('resize', handleResize);
          scrollableParent.addEventListener('scroll', handleScroll);
        });
      },
      { deep: true },
    );
  }; const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    if (!togglerElement || !dropdownElement) return;

    const updateDropdownAttributes = () => {
      togglerRect.value = togglerElement.getBoundingClientRect();
      dropdownRect.value = dropdownElement.getBoundingClientRect();
      dropdownWidth.value = `${togglerRect.value.width}px`;
      dropdownBottom.value = `${window.innerHeight - togglerRect.value.top}px`;
      dropdownTop.value = `${
        window.innerHeight - togglerRect.value.bottom - dropdownRect.value.height
      }px`;
      dropdownLeft.value = `${togglerRect.value.left}px`;
    };

    const handleResize = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    const handleScroll = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    watch(
      [isDropdownDisplayed, dropdownContent],
      ([newVal, _]) => {
        const scrollableParent = getFirstScrollableParent(togglerElement);
        if (!newVal) {
          window.removeEventListener('resize', handleResize);
          window.removeEventListener('scroll', handleScroll);
          scrollableParent.removeEventListener('resize', handleResize);
          scrollableParent.removeEventListener('scroll', handleScroll);
          return;
        }

        requestAnimationFrame(() => {
          const distanceFromBottom =
            window.innerHeight - togglerElement.getBoundingClientRect().bottom;
          const distanceFromTop = togglerElement.getBoundingClientRect().top;
          const dropdownHeight = dropdownElement.offsetHeight;

          isDirectedUpwards.value = isUpwardPreferred
            ? distanceFromTop > dropdownHeight
            : distanceFromBottom < dropdownHeight &&
              distanceFromTop > dropdownHeight;

          updateDropdownAttributes();
          window.addEventListener('resize', handleResize);
          window.addEventListener('scroll', handleScroll);
          scrollableParent.addEventListener('resize', handleResize);
          scrollableParent.addEventListener('scroll', handleScroll);
        });
      },
      { deep: true },
    );
  }; We pass isDropdownDisplayed and dropdownContent so we can react to their updates. isDropdownDisplayed dropdownContent We also pass togglerElement and dropdownElement which we need to calculate the position. togglerElement dropdownElement Finally, there’s isUpwardPreferred in case you want the dropdown above the toggler by default. isUpwardPreferred Time to Relax and Enjoy In your component, you will need something like this (I assume you have added refs to your toggler and dropdown in the template): const {
  autodetectPosition,
  dropdownTop,
  dropdownBottom,
  dropdownLeft,
  dropdownWidth,
  isDirectedUpwards,
} = useDropdownAttributes();

const togglerRef = ref<HTMLElement>();
const dropdownRef = ref<HTMLElement>();

const isDropdownShown = ref(false);

onMounted(() => {
  autodetectPosition(isDropdownShown, togglerRef.value?.$el, dropdownRef.value?.$el);
}); const {
  autodetectPosition,
  dropdownTop,
  dropdownBottom,
  dropdownLeft,
  dropdownWidth,
  isDirectedUpwards,
} = useDropdownAttributes();

const togglerRef = ref<HTMLElement>();
const dropdownRef = ref<HTMLElement>();

const isDropdownShown = ref(false);

onMounted(() => {
  autodetectPosition(isDropdownShown, togglerRef.value?.$el, dropdownRef.value?.$el);
}); And the CSS will look like this: .dropdown {
  position: fixed;
  bottom: v-bind('isDirectedUpwards ? dropdownBottom : dropdownTop');
  left: v-bind('dropdownLeft');

  width: v-bind('dropdownWidth');
  min-width: 0;
} .dropdown {
  position: fixed;
  bottom: v-bind('isDirectedUpwards ? dropdownBottom : dropdownTop');
  left: v-bind('dropdownLeft');

  width: v-bind('dropdownWidth');
  min-width: 0;
} Voilà. The dropdown is displayed properly even when overflowing and moves above the toggler if there isn’t enough space below. And since we’re at the end of the article, I’d love to leave you with something cheerful—but I’m out of ideas. So, I'm afraid "good luck" is all I have this time. Good luck. 👋 You can find the complete code on GitHub. You can find the complete code on GitHub . GitHub

Proper Display of Custom Dropdown Elements: A How-to Guide

العرض الصحيح لعناصر القائمة المنسدلة المخصصة: دليل إرشادي

Σωστή εμφάνιση προσαρμοσμένων αναπτυσσόμενων στοιχείων: Οδηγός πώς να το κάνετε

Presentación correcta de elementos de descarga personalizados: una guía de cómo

カスタム ドロップダウン要素の適切な表示: ハウツー ガイド

사용자 정의 드롭다운 요소의 적절한 표시: 방법 가이드

Правилно прикажување на приспособени паѓачки елементи: Водич како да се

Pontšo ya maleba ya Dielemente tša go Theoga tša Tlwaelo: Tlhahlo ya Tsela ya go Dira

Prawidłowe wyświetlanie niestandardowych elementów rozwijania: przewodnik

Одговарајући приказ прилагођених падајућих елемената: водич са упутствима

Özel Açılır Öğelerin Doğru Görüntülenmesi: Nasıl Yapılır Kılavuzu

حسب ضرورت ڈراپ ڈاؤن عناصر کا مناسب ڈسپلے: ایک گائیڈ

Developers’ Insights on Game Design Elements: Pros and Cons

Authors:
(1) Clauvin Almeida, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil;
(2) Marcos Kalinowski, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil;
(3) Anderson Uchoa, Federal University of Ceara (UFC), Itapaje, Brazil;
(4) Bruno Feijo, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil. Table of Links Abstract and 1 Introduction 2. Background and Related Work and 2.1. Gamification 2.2. Game Design Elements and 2.3. Gamification Effects 2.4. Related Work on Gamification Negative Effects 3. Systematic Mapping and 3.1. The Research Questions 3.2. Search Strategy and 3.3. Inclusion and Exclusion Criteria 3.4. Applying the Search Strategy 3.5. Data Extraction 4. Systematic Mapping Results 5. Focus Group: Developer Perception on the Negative Effects of Game Design Elements 5.1. Context and Participant Characterization 5.2. Focus Group Design 5.3. The Developers’ Perception on The Negative Effects 5.4. On the Perceived Usefulness, Ease of use and Intent of Adoption of Mapped Negative Effects 5.5. Participant Feedback 6. Limitations 7. Concluding Remarks 7.1. Future Research Directions Acknowledgements and References 5.2. Focus Group Design We carefully designed and performed our focus group by following the guideline proposed by Kontio et al. [107]. Figure 6 depicts the steps adopted throughout the focus group. We organized these steps in three major phases: (1) Preparation for the focus group session; (2) Discussion by group of game design elements; and (3) Discussion on the perception of the mapped negative effects. We describe each phase and step hereafter. Phase 1: Preparation for the focus group session – This phase consists of the collection of preliminary resources for supporting the execution of the focus group session. For this purpose, we follow two steps. Step 1 consisted of recruiting developers with experience in gamification to engage in discussions. As mentioned in Section 5.1, we contacted developers of the VazaZika development team for participating in our study. We obtained the acceptance of four developers via Consent Form in which we explain our research goals, information about the waiver statements, and that the information provided by each participant will be treated confidentially and used for study purposes only. Step 2 aimed to collecting basic information to characterize the participants via the Participant Characterization Form. Our major goal was profiling each developer, so we could better interpret our study results. We opted for asking short and simple questions in order to prevent participants from being tired or discouraged to participate in discussions right after filling out the form. More specifically, we collected data on the education level, years of experience with software development (academy and industry), the number of software projects they participated, and the level of knowledge about gamification and game design elements (see Table 16). Due to the geographic distribution of our participants, we used an online environment to promote discussions on the negative effects of game design elements. Figure 7 illustrates the virtual template that we designed using the MURAL online tool[2]. In practice, by using this tool, we were able to build an interactive mural to facilitate the conduction of the focus group session. Our mural has eight well-defined sections. Sections A to G aimed at driving the discussion regarding the negative effects of game design elements. In order to facilitate discussions, we have semantically grouped the game design elements by section as follow: (A) Badges and Rewards; (B) Competitions, Challenges, and Goals; (C) Leaderboards and Rankings; (D) Points, XPs, and Virtual Currencies; Feedback and Achievements; (E) Avatars; and (F) Quizzes. Finally, Section G aimed at driving the discussion and capturing the level of agreement on the usefulness, ease to use, and intention to use the information on potential negative effects of game design elements. Figure 8 illustrates the template that we have defined for each aforementioned section. A section is composed of four parts (1, 2, 3, and 4). Part 1 contains a short description of the involved game design elements and the identified negative effects based on the literature. Part 2 is designed for capturing votes on the awareness degree concern the negative effects based on a four-point scale: completely unaware, mostly unaware, mostly aware, and completely aware. Finally, parts 3 and 4 were designed for participants to add notes on the Pros and Cons of using the game design elements, respectively. Phase 2: Discussion by game design elements – This phase consists in collecting data regarding the developer’s perception of the negative effects identified in the literature. As aforementioned, we have divide the game design elements in groups to facilitate the discussions and used a Mural discussion canvas. Thus, each group of game design elements is discussed in isolation. We defined three steps as follows. Step 1 aimed at introducing each group of game design elements, and the negative effects. For this purpose, the moderator of the session read this information out loud (part 1 of Figure 8). Next, in Step 2, we asked each participant to assign one vote to the awareness degree of the group of game design elements according to the four-point scale depicted in part 2 of Figure 8. Each participant voted individually, without knowing the votes of his colleagues. At the end, the moderator showed the number of votes per awareness agree. Finally, in Step 3, we asked the participants to discuss and elicit Pros and Cons of using the game design elements. In this step, each comment should be documented as a note in the appropriate part: part 3 for positive comments and part 4 for negative ones, as shown in Figure 8. The note was just a brief summary of a Pro or a Con, typically taken within seconds, and we constantly asked participants to share knowledge and experiences surrounding the use of each game design element, to enrich the discussions and understandings. Additionally, whenever the moderator felt that a note is poorly written, he asked the participants to provide further considerations on the note. Phase 3: Discussion about the perception of the mapped negative effects – After discussing all groups of game design elements, the focus group session ended with a final discussion about the perceptions regarding the mapped negative effects. This phase has two steps described as follows. In Step 1, based on the main constructs of the Technology Acceptance Model (TAM) [113], we asked each participant to assign one vote to their agreement with each of the following statements (as illustrated in Section G of Figure 7): (1) I find the information on potential negative effects of game design elements useful to support game design element adoption decisions; (2) I find the information on potential negative effects of game design element easy to use to support game design element adoption decisions; and (3) I intend to use the information on potential negative effects of game design element to support game design element adoption decisions. We have used the five-point scale depicted in Figure 7 (G). Finally, Step 2 aimed at collecting data about the participant’s experience with the focus group session. Thus, by the end of the focus group session, we asked participants to fill out a Follow-up Form. We aimed at assuring that each developer felt confident and comfortable to discuss the negative effect of game design elements. We emphasize that the focus group session was conducted online via a Zoom Meeting. Additionally, we kept video and audio records of the session to support the data analysis. We often accessed the video and audio records for understanding what developers meant with each note. The focus group session was conducted in January 24, 2022 lasting one and a half hours. This paper is available on arxiv under CC BY 4.0 DEED license. [2] https://www.mural.co/ Authors: (1) Clauvin Almeida, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (2) Marcos Kalinowski, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (3) Anderson Uchoa, Federal University of Ceara (UFC), Itapaje, Brazil; (4) Bruno Feijo, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil. Authors: Authors: (1) Clauvin Almeida, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (2) Marcos Kalinowski, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (3) Anderson Uchoa, Federal University of Ceara (UFC), Itapaje, Brazil; (4) Bruno Feijo, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2. Background and Related Work and 2.1. Gamification 2. Background and Related Work and 2.1. Gamification 2.2. Game Design Elements and 2.3. Gamification Effects 2.2. Game Design Elements and 2.3. Gamification Effects 2.4. Related Work on Gamification Negative Effects 2.4. Related Work on Gamification Negative Effects 3. Systematic Mapping and 3.1. The Research Questions 3. Systematic Mapping and 3.1. The Research Questions 3.2. Search Strategy and 3.3. Inclusion and Exclusion Criteria 3.2. Search Strategy and 3.3. Inclusion and Exclusion Criteria 3.4. Applying the Search Strategy 3.4. Applying the Search Strategy 3.5. Data Extraction 3.5. Data Extraction 4. Systematic Mapping Results 4. Systematic Mapping Results 5. Focus Group: Developer Perception on the Negative Effects of Game Design Elements 5. Focus Group: Developer Perception on the Negative Effects of Game Design Elements 5.1. Context and Participant Characterization 5.1. Context and Participant Characterization 5.2. Focus Group Design 5.2. Focus Group Design 5.3. The Developers’ Perception on The Negative Effects 5.3. The Developers’ Perception on The Negative Effects 5.4. On the Perceived Usefulness, Ease of use and Intent of Adoption of Mapped Negative Effects 5.4. On the Perceived Usefulness, Ease of use and Intent of Adoption of Mapped Negative Effects 5.5. Participant Feedback 5.5. Participant Feedback 6. Limitations 6. Limitations 7. Concluding Remarks 7. Concluding Remarks 7.1. Future Research Directions 7.1. Future Research Directions Acknowledgements and References Acknowledgements and References 5.2. Focus Group Design We carefully designed and performed our focus group by following the guideline proposed by Kontio et al. [107]. Figure 6 depicts the steps adopted throughout the focus group. We organized these steps in three major phases: (1) Preparation for the focus group session; (2) Discussion by group of game design elements; and (3) Discussion on the perception of the mapped negative effects. We describe each phase and step hereafter. Phase 1: Preparation for the focus group session – This phase consists of the collection of preliminary resources for supporting the execution of the focus group session. For this purpose, we follow two steps. Step 1 consisted of recruiting developers with experience in gamification to engage in discussions. As mentioned in Section 5.1, we contacted developers of the VazaZika development team for participating in our study. We obtained the acceptance of four developers via Consent Form in which we explain our research goals, information about the waiver statements, and that the information provided by each participant will be treated confidentially and used for study purposes only. Step 2 aimed to collecting basic information to characterize the participants via the Participant Characterization Form. Our major goal was profiling each developer, so we could better interpret our study results. We opted for asking short and simple questions in order to prevent participants from being tired or discouraged to participate in discussions right after filling out the form. More specifically, we collected data on the education level, years of experience with software development (academy and industry), the number of software projects they participated, and the level of knowledge about gamification and game design elements (see Table 16). Phase 1: Preparation for the focus group session Step 1 Step 2 Due to the geographic distribution of our participants, we used an online environment to promote discussions on the negative effects of game design elements. Figure 7 illustrates the virtual template that we designed using the MURAL online tool[2]. In practice, by using this tool, we were able to build an interactive mural to facilitate the conduction of the focus group session. Our mural has eight well-defined sections. Sections A to G aimed at driving the discussion regarding the negative effects of game design elements. In order to facilitate discussions, we have semantically grouped the game design elements by section as follow: (A) Badges and Rewards; (B) Competitions, Challenges, and Goals; (C) Leaderboards and Rankings; (D) Points, XPs, and Virtual Currencies; Feedback and Achievements; (E) Avatars; and (F) Quizzes. Finally, Section G aimed at driving the discussion and capturing the level of agreement on the usefulness, ease to use, and intention to use the information on potential negative effects of game design elements. Figure 8 illustrates the template that we have defined for each aforementioned section. A section is composed of four parts (1, 2, 3, and 4). Part 1 contains a short description of the involved game design elements and the identified negative effects based on the literature. Part 2 is designed for capturing votes on the awareness degree concern the negative effects based on a four-point scale: completely unaware, mostly unaware, mostly aware, and completely aware. Finally, parts 3 and 4 were designed for participants to add notes on the Pros and Cons of using the game design elements, respectively. Phase 2: Discussion by game design elements – This phase consists in collecting data regarding the developer’s perception of the negative effects identified in the literature. As aforementioned, we have divide the game design elements in groups to facilitate the discussions and used a Mural discussion canvas. Thus, each group of game design elements is discussed in isolation. We Phase 2: Discussion by game design elements defined three steps as follows. Step 1 aimed at introducing each group of game design elements, and the negative effects. For this purpose, the moderator of the session read this information out loud (part 1 of Figure 8). Next, in Step 2 , we asked each participant to assign one vote to the awareness degree of the group of game design elements according to the four-point scale depicted in part 2 of Figure 8. Each participant voted individually, without knowing the votes of his colleagues. At the end, the moderator showed the number of votes per awareness agree. Finally, in Step 3 , we asked the participants to discuss and elicit Pros and Cons of using the game design elements. In this step, each comment should be documented as a note in the appropriate part: part 3 for positive comments and part 4 for negative ones, as shown in Figure 8. The note was just a brief summary of a Pro or a Con, typically taken within seconds, and we constantly asked participants to share knowledge and experiences surrounding the use of each game design element, to enrich the discussions and understandings. Additionally, whenever the moderator felt that a note is poorly written, he asked the participants to provide further considerations on the note. Step 1 Step 2 Step 3 Phase 3: Discussion about the perception of the mapped negative effects – After discussing all groups of game design elements, the focus group session ended with a final discussion about the perceptions regarding the mapped negative effects. This phase has two steps described as follows. In Step 1 , based on the main constructs of the Technology Acceptance Model (TAM) [113], we asked each participant to assign one vote to their agreement with each of the following statements (as illustrated in Section G of Figure 7): (1) I find the information on potential negative effects of game design elements useful to support game design element adoption decisions; (2) I find the information on potential negative effects of game design element easy to use to support game design element adoption decisions; and (3) I intend to use the information on potential negative effects of game design element to support game design element adoption decisions. We have used the five-point scale depicted in Figure 7 (G). Finally, Step 2 aimed at collecting data about the participant’s experience with the focus group session. Thus, by the end of the focus group session, we asked participants to fill out a Follow-up Form. We aimed at assuring that each developer felt confident and comfortable to discuss the negative effect of game design elements. Phase 3: Discussion about the perception of the mapped negative effects Step 1 Step 2 We emphasize that the focus group session was conducted online via a Zoom Meeting. Additionally, we kept video and audio records of the session to support the data analysis. We often accessed the video and audio records for understanding what developers meant with each note. The focus group session was conducted in January 24, 2022 lasting one and a half hours. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv [2] https://www.mural.co/

Focus Group Insights on Game Design Elements

What to Watch for: 5 Must-Have Elements in Crypto Whitepapers

Kunas uñjañasa: 5 Elementos Must-Have en Cripto Janq’u qillqatanaka

За какво да внимавате: 5 задължителни елемента в крипто белите книги

Na šta treba obratiti pažnju: 5 obaveznih elemenata u kripto bijelim papirima

Worauf Sie achten sollten: 5 unverzichtbare Elemente in Krypto-Whitepapers

Qué tener en cuenta: 5 elementos imprescindibles en los documentos técnicos sobre criptomonedas

Zer ikusi: 5 elementu ezinbestekoak Crypto Whitepapers

O que hai que ter en conta: 5 elementos imprescindibles nos documentos brancos de cripto

למה לצפות: 5 אלמנטים חובה במסמכי קריפטו

注目すべき点: 暗号通貨のホワイトペーパーに必須の 5 つの要素

Kam jāpievērš uzmanība: 5 obligātie elementi kriptogrāfijās

สิ่งที่ต้องจับตามอง: 5 องค์ประกอบที่ต้องมีใน Crypto Whitepapers

Nämä tomaşa etmeli: Kripto sahypalarynda 5 element bolmaly

If you’ve been writing Go code for a while, you’ve probably come across range loops. They’re elegant, concise, and incredibly handy for iterating over slices, maps, and channels. But did you know that their behavior can sometimes be counterintuitive, leading to subtle bugs in your code? In this article, I’ll break down the mechanics of range loops, explain why these quirks occur, and share actionable tips to avoid common pitfalls. By the end, you’ll have a deeper understanding of Go and be better equipped to write reliable, bug-free code. 🚀 What Makes Range Loops Tricky? At first glance, range loops in Go appear straightforward. Here’s an example you’ve likely seen: codenumbers := []int{1, 2, 3, 4, 5}  
for index, value := range numbers {  
    fmt.Printf("Index: %d, Value: %d\n", index, value)  
} This prints the index and value for each element in the slice. Simple, right? But here’s where things get interesting (and potentially frustrating). The Underlying Mechanics of Range When you use range, Go creates a copy of the value you’re iterating over. For slices, this means you’re not directly accessing the elements but working with their copies. This subtle detail can lead to unexpected behavior. Take this example: codewords := []string{"Go", "is", "awesome"}  
wordPointers := []*string{}  

for _, word := range words {  
    wordPointers = append(wordPointers, &word)  
}  

for _, pointer := range wordPointers {  
    fmt.Println(*pointer)  
} You might expect this to print: Go  
is  
awesome But instead, you’ll see: awesome  
awesome  
awesome Why? Because word is a single variable reused in every iteration. The loop appends the same variable’s address each time, and by the end of the loop, word holds the value of the last element. Avoiding Common Pitfalls Here are some tips to keep your range loops bug-free: Understand Copying Behavior:If you’re modifying elements, remember thatrange loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements.
for i := range numbers {  
    numbers[i] *= 2  
}  




Be Cautious with Pointers:If you need to capture references to elements, use the index instead of the loop variable.
for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
}  




Debug Complex Loops:Usefmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Why This Matters Understanding these quirks isn’t just about avoiding bugs—it’s about mastering Go. As you tackle more complex projects, these small details can have significant impacts on performance, correctness, and maintainability. This article is part of a series I’m writing to explore common mistakes in Go programming. The first topic, range loops, is something many developers encounter but don’t fully understand until they’ve run into a bug. Final Thoughts Range loops are one of Go’s most powerful tools, but like any tool, they come with nuances. By understanding how they evaluate and iterate over elements, you can write cleaner, more reliable code. If you’ve ever been bitten by a range loop bug—or have tips of your own—I’d love to hear from you! Let’s share knowledge and grow as a community. 🔗 Read the full article on my LinkedIn For more insights like this, follow my journey in exploring the intricacies of Go programming. 🚀 If you’ve been writing Go code for a while, you’ve probably come across range loops. They’re elegant, concise, and incredibly handy for iterating over slices, maps, and channels. But did you know that their behavior can sometimes be counterintuitive, leading to subtle bugs in your code? range In this article, I’ll break down the mechanics of range loops, explain why these quirks occur, and share actionable tips to avoid common pitfalls. By the end, you’ll have a deeper understanding of Go and be better equipped to write reliable, bug-free code. 🚀 range What Makes Range Loops Tricky? What Makes Range At first glance, range loops in Go appear straightforward. Here’s an example you’ve likely seen: range codenumbers := []int{1, 2, 3, 4, 5}  
for index, value := range numbers {  
    fmt.Printf("Index: %d, Value: %d\n", index, value)  
} codenumbers := []int{1, 2, 3, 4, 5}  
for index, value := range numbers {  
    fmt.Printf("Index: %d, Value: %d\n", index, value)  
} This prints the index and value for each element in the slice. Simple, right? But here’s where things get interesting (and potentially frustrating). The Underlying Mechanics of Range The Underlying Mechanics of Range When you use range , Go creates a copy of the value you’re iterating over. For slices, this means you’re not directly accessing the elements but working with their copies. This subtle detail can lead to unexpected behavior. range Take this example: codewords := []string{"Go", "is", "awesome"}  
wordPointers := []*string{}  

for _, word := range words {  
    wordPointers = append(wordPointers, &word)  
}  

for _, pointer := range wordPointers {  
    fmt.Println(*pointer)  
} codewords := []string{"Go", "is", "awesome"}  
wordPointers := []*string{}  

for _, word := range words {  
    wordPointers = append(wordPointers, &word)  
}  

for _, pointer := range wordPointers {  
    fmt.Println(*pointer)  
} You might expect this to print: Go  
is  
awesome Go  
is  
awesome But instead, you’ll see: awesome  
awesome  
awesome awesome  
awesome  
awesome Why? Because word is a single variable reused in every iteration. The loop appends the same variable’s address each time, and by the end of the loop, word holds the value of the last element. word word Avoiding Common Pitfalls Avoiding Common Pitfalls Here are some tips to keep your range loops bug-free: range Understand Copying Behavior:If you’re modifying elements, remember thatrange loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements.
for i := range numbers {  
    numbers[i] *= 2  
} Be Cautious with Pointers:If you need to capture references to elements, use the index instead of the loop variable.
for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} Debug Complex Loops:Usefmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Understand Copying Behavior:If you’re modifying elements, remember thatrange loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements. for i := range numbers {  
    numbers[i] *= 2  
} Understand Copying Behavior : If you’re modifying elements, remember that range loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements. Understand Copying Behavior range for i := range numbers {  
    numbers[i] *= 2  
} for i := range numbers {  
    numbers[i] *= 2  
} Be Cautious with Pointers:If you need to capture references to elements, use the index instead of the loop variable. for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} Be Cautious with Pointers : If you need to capture references to elements, use the index instead of the loop variable. Be Cautious with Pointers for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} Debug Complex Loops:Usefmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Debug Complex Loops : Use fmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Debug Complex Loops fmt.Printf Why This Matters Why This Matters Understanding these quirks isn’t just about avoiding bugs—it’s about mastering Go. As you tackle more complex projects, these small details can have significant impacts on performance, correctness, and maintainability. This article is part of a series I’m writing to explore common mistakes in Go programming. The first topic, range loops, is something many developers encounter but don’t fully understand until they’ve run into a bug. range Final Thoughts Final Thoughts Range loops are one of Go’s most powerful tools, but like any tool, they come with nuances. By understanding how they evaluate and iterate over elements, you can write cleaner, more reliable code. Range If you’ve ever been bitten by a range loop bug—or have tips of your own—I’d love to hear from you! Let’s share knowledge and grow as a community. range 🔗 Read the full article on my LinkedIn Read the full article on my LinkedIn For more insights like this, follow my journey in exploring the intricacies of Go programming. 🚀

Unlock the Secrets of Range Loops: How Element Evaluation Affects Your Go Code

Recently came an interesting task, changing custom SVG, to a Webflow project for the animation. I thought it was no big deal, opened a Figma, took the source code of the SVG, threw it in and .... didn't work 😔 Researching the problem, it turned out that the library that animates SVG works directly with rect elements inside the same SVG. Well again no problem I thought :), let's just rename all layers to Rect and we'll be happy. Renamed, I looked at the SVG source code and I don't see rect :( Then, I sat down much more comfortably in my chair and started researching more efficiently. It turned out that for SVG to understand the elements we want to animate as recr we need to draw them.... drum roll - through Frames. Started testing, and everything works. But now there is another problem: How to automate this process? We already have a lot of drawn illustrations, and we don't want to redo them. Well, since we are working in Frames, we have found a way out, need to create the plugin that will wrap all elements in frames. The source code of the Plugin: const selectedNodes = figma.currentPage.selection;

if (selectedNodes.length === 0) {
  figma.notify("Please select at least one layer.");
} else {
  selectedNodes.forEach(node => {
    const frame = figma.createFrame();
    frame.resize(node.width, node.height);
    frame.x = node.x;
    frame.y = node.y;
    frame.appendChild(node);
    node.x = 0;
    node.y = 0;
  });

  figma.notify("All selected layers are wrapped in frames!");
}

figma.closePlugin(); or download the project on GitHub :-) Result: 30 minutes of code and all animations work, work for the future is done. Conclusion: if you can't find interesting tasks, they will find you themselves. Automate everything :) Recently came an interesting task, changing custom SVG, to a Webflow project for the animation. I thought it was no big deal, opened a Figma, took the source code of the SVG, threw it in and .... didn't work 😔 didn't work didn't work Researching the problem, it turned out that the library that animates SVG works directly with rect elements inside the same SVG. Well again no problem I thought :), let's just rename all layers to Rect and we'll be happy. rect Renamed, I looked at the SVG source code and I don't see rect :( rect Then, I sat down much more comfortably in my chair and started researching more efficiently. It turned out that for SVG to understand the elements we want to animate as recr we need to draw them.... drum roll - through Frames. recr Started testing, and everything works. But now there is another problem: How to automate this process? How to automate this process? We already have a lot of drawn illustrations, and we don't want to redo them. Well, since we are working in Frames, we have found a way out, need to create the plugin that will wrap all elements in frames. plugin The source code of the Plugin: const selectedNodes = figma.currentPage.selection;

if (selectedNodes.length === 0) {
  figma.notify("Please select at least one layer.");
} else {
  selectedNodes.forEach(node => {
    const frame = figma.createFrame();
    frame.resize(node.width, node.height);
    frame.x = node.x;
    frame.y = node.y;
    frame.appendChild(node);
    node.x = 0;
    node.y = 0;
  });

  figma.notify("All selected layers are wrapped in frames!");
}

figma.closePlugin(); const selectedNodes = figma.currentPage.selection;

if (selectedNodes.length === 0) {
  figma.notify("Please select at least one layer.");
} else {
  selectedNodes.forEach(node => {
    const frame = figma.createFrame();
    frame.resize(node.width, node.height);
    frame.x = node.x;
    frame.y = node.y;
    frame.appendChild(node);
    node.x = 0;
    node.y = 0;
  });

  figma.notify("All selected layers are wrapped in frames!");
}

figma.closePlugin(); or download the project on GitHub :-) GitHub Result: 30 minutes of code and all animations work, work for the future is done. Conclusion: if you can't find interesting tasks, they will find you themselves. Automate everything :)

Tutorial: How to Turn Figma Files to SVG with Rect Elements

Падручнік: як ператварыць файлы Figma у SVG з элементамі Rect

Урок: Как да превърнете Figma файлове в SVG с Rect елементи

Tutorial: Cómo convertir archivos Figma a SVG con elementos Rect

آموزش: نحوه تبدیل فایل های Figma به SVG با عناصر Rect

Tutorial: Ki jan yo vire fichye Figma nan SVG ak eleman Rect

Tutorial: come trasformare i file Figma in SVG con elementi Rect

מדריך: כיצד להפוך קבצי Figma ל-SVG עם רכיבי Rect

チュートリアル: Figma ファイルを Rect 要素付きの SVG に変換する方法

Упатство: Како да ги претворите Figma-датотеките во SVG со Rect Elements

Samouczek: Jak przekształcić pliki Figma do formatu SVG za pomocą elementów Rect

Tutorial: Si t'i ktheni skedarët Figma në SVG me Elemente Rect

Qo'llanma: Figma fayllarini to'g'ri elementlar bilan SVGga qanday aylantirish mumkin

Stories, News & Mentions about ELEMENT

Categories

Trending Topics

Stories, News & Mentions about ELEMENT

Element’s Stories on HackerNoon

Element's News & Mentions

Categories

Trending Topics