profile
viewpoint
Alex Zherdev alexzherdev @acl-services Vancouver, BC An inquiring mind. JavaScript, React, tooling.

alexzherdev/pandemic 20

A Redux-based implementation of the board game Pandemic.

alexzherdev/sms 6

School Management System

alexzherdev/foosballtracker 1

Keeping track of foosball match scores

alexzherdev/active_model_serializers 0

ActiveModel::Serializer implementation and Rails hooks

alexzherdev/add-module-exports-webpack-plugin 0

Add `module.exports` for Babel and TypeScript compiled code

alexzherdev/babel 0

:tropical_fish: Babel is a compiler for writing next generation JavaScript.

alexzherdev/create-react-app 0

Create React apps with no build configuration.

alexzherdev/deco-ide 0

The React Native IDE

alexzherdev/dev.to 0

Where programmers share ideas and help each other grow

push eventalexzherdev/pandemic

Alex Zherdev

commit sha 2e0ae749dcc3819d1013a118814b8069ea4eb268

Remove 1-player mode

view details

push time in 23 days

delete branch alexzherdev/pandemic

delete branch : master

delete time in 23 days

create barnchalexzherdev/pandemic

branch : main

created branch time in 23 days

delete branch alexzherdev/syntaxify

delete branch : master

delete time in 23 days

create barnchalexzherdev/syntaxify

branch : main

created branch time in 23 days

PublicEvent

push eventalexzherdev/pandemic

Alex Zherdev

commit sha d1738bbeb62b1d4bb1e9477b81bb1cd06c73e0bf

Remove 1-player mode

view details

push time in a month

pull request commentacl-services/paprika

Ux-157 FormElement api simplification

I generally agree with the above. What we're trying to do is the opposite of what's recommended here https://www.youtube.com/watch?v=AiJ8tRRH0f8 (which I agree with)

tristanjasper

comment created time in a month

issue commentforem/forem

Ellipsis menu in post manage page non-functional

Yep exactly—I traced it back to https://github.com/forem/forem/pull/8778 by @ludwiczakpawel. If he's not available I might be able to fix this up if we can decide which naming to follow.

alexzherdev

comment created time in a month

issue openedforem/forem

Ellipsis menu in post manage page non-functional

<!-- Before creating a bug report, try disabling browser extensions to see if the bug is still present. -->

<!-- If you're having trouble updating your profile, it is likely because you logged in separately with GitHub & Twitter. Please check if this is the case before creating a bug report, and email yo@dev.to so we can merge your accounts. -->

Describe the bug

In the post manage page, clicking the "..." menu on the right seems to do nothing.

To Reproduce

<!-- Steps to reproduce the behavior: -->

  1. Go to https://dev.to/user/post-slug/manage
  2. Click on ... on the right
  3. Nothing happens

Expected behavior

I'm expecting a dropdown menu to appear? According to the markup, it contains an "Archive Post" button.

Screenshots

devtoellipsis

Desktop (please complete the following information):

  • OS, version: macOS 10.14.6
  • Browser, version: Chrome 84.0.4147.135

Smartphone (please complete the following information):

  • Device: iPhone XS
  • OS, version: iOS 13.5
  • Browser, version: Chrome 85.0.4183.72

Additional context

Doesn't seem to work in the iOS native app either.

created time in a month

Pull request review commentacl-services/paprika

UXD-153-constants-refactor

 /* eslint-disable react/button-has-type */  import React from "react";+import * as constants from "@paprika/constants/lib/Constants";

This here is a problem. It's fine to create an internally shared package to centralize those constants, but if the consumers need to install this package into their apps to access constants, we're signing up for version mismatches in the future as the package gets updates. I think the alternative would be to re-export so that they'd access e.g. ButtonGroup.kinds.PRIMARY

KDarcey

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentacl-services/paprika

Ux-157 FormElement api simplification

Critiquing without offering an alternative is unfair but I'll try to offer at least something at the end 😄 I want to throw in a general idea: I think it's commendable to try to ease the burden for consumers, but this should always be weighed against complexity or potential for issues within the library. If the library's code becomes too convoluted or otherwise hard to maintain, we're ultimately doing a disservice to the consumers.

Particularly in this case, one thing I'm seeing is we're essentially making Content depend (in the npm/package sense) on all the different form components (input, checkbox, etc.). It's subtle, but the code that knows how to properly clone all the different kinds of components assumes a certain API (especially children) of those components. This is most obvious with DatePicker: the cloning code used by Content knows that DatePicker has a single child which is the DatePicker's "input". If we change that API in a major bump for DatePicker, Content will break when used in conjunction with that new version.

This isn't a normal dependency though since FormElement doesn't import or compose the form components. It would be a peer dependency, because it's really saying hey, this version of me works in the presence of these versions of all those other components. It would actually be an optional peer dependency since using FormElement doesn't require each of the form components to be present. But honestly having any such sort of dependency seems weird.

I don't see a perfect way out, I feel like we may have painted ourselves into a corner introducing this generic FormElement component. The best thing I can see would be for us to rename the properties passed into the render prop so that they can be spread onto the child component without destructuring like so:

<FormElement.Content>
  {a11yProps => (
    <Input
      {...a11yProps}
      {...otherProps}
    />
  )}
</FormElement.Content>

where a11yProps is { id: "someId", "aria-describedby": "something else" }. Just makes it a bit less tedious.

tristanjasper

comment created time in a month

Pull request review commentacl-services/paprika

Star 242 refractor css

 import tokens from "@paprika/tokens"; import { truncateText } from "@paprika/stylers/lib/includes"; import { toInt } from "@paprika/stylers/lib/helpers"; -export const ExternalLink = styled.a`+export const ExternalLinkWrapper = styled.a`+  ${props => `   align-items: center;   border-radius: ${tokens.border.radius};   color: ${tokens.textColor.link};   display: inline-flex;   max-width: 100%;   position: relative; -  ${({ iconFontSize }) => `padding: 1px ${iconFontSize + toInt(tokens.spaceLg)}px 1px ${tokens.spaceSm};`}+  ${`padding: 1px ${props.iconFontSize + toInt(tokens.spaceLg)}px 1px ${tokens.spaceSm};`}

Does line 7 also need css for syntax highlighting?

I'm ambivalent but just sharing some links. Overall this approach seems similar to this, correct? https://twitter.com/NikkitaFTW/status/1262423045874089990 And FWIW I found another one in the comments: https://twitter.com/Saeris/status/1262441528078688256

KaanDarcey

comment created time in 3 months

issue openedfastify/help

Lacking documentation clarity in error serialization

You have already researched for similiar issues?

Yes

What are you trying to achieve or the steps to reproduce?

The interplay between various hooks and the custom error handler isn't well documented as far as I can see. In particular, I'm using a preSerialization hook to enforce JSON:API format. I'm also using a custom error handler with setErrorHandler.

app.addHook('preSerialization', async (req, reply, payload) => {
  return serializer.serialize('items', payload);
});

app.setErrorHandler(async (error, req, reply) => {
  // sending error to airbrake
  // as well as some logic like the following
  if (error instanceof SomeError) {
    throw new SomeOtherError();
  }
  throw error;
});

What was the result you received?

When I throw or return an error object from the error handler, it doesn't go through preSerialization. I thought I could, instead of throwing, serialize the error right in the handler like

app.setErrorHandler(async (error, req, reply) => {
  // [...]
  return serializer.serializeError(error);
});

but then preSerialization starts getting invoked on top of serializeError result which produces an incorrect payload. What I landed on is (using reply.send because I also want to set the content type):

app.setErrorHandler(async (error, req, reply) => {
  [...]
  reply.type('application/json').send(JSON.stringify(serializer.serializeError(error)));
});

Then preSerialization is not invoked since the payload is a string. But I'm wondering if this is the right way.

What did you expect?

Ultimately, I'd like to see more information in the docs regarding how the custom error handler affects the hooks and really, how it fits into the lifecycle. E.g., it was unexpected that I could return an object from the error handler and have it be serialized as though it was a regular response payload. In addition, this bit in preSerialization doesn't seem fully correct? (It seems not to be called if payload is an Error as well)

Note: the hook is NOT called if the payload is a string, a Buffer, a stream or null.

Context

  • node version: 12.16.1
  • fastify version: 2.12.1
  • os: macOS 10.14.6
  • any other relevant information:

created time in 3 months

more