atoko

Hello! One of the main challenges of figuring a JSX syntax out is what to do about the “children” prop.

Experientially, typescript still has a bit of trouble figuring out the right types for these nested structures. Even with a typed jsx function it sometimes doesn’t infer correctly, so providing plugin capability would take a very careful hand

I’m working on the documentation, but I have a useful implementation of <GithubActions > JSX:

https://github.com/levicape/fourtwo

The best way to use template JSX is either with a CLI, or by using #! pragma to output the constructed yaml after using a builder.

Thanks!

More concisely: it’s not always the case that prop drilling is possible within a component hierarchy. In a more involved application you store this object in context.

Is what you are describing compatible with this pattern? How does this inform the design of RSCs and as a developer, how can I expect this to affect me?

I wonder if the omission of React Context in this example is intentional. Do you think Context is compatible with suspense? In the sense that posts is being passed to components as props three times over.

Is it because each component is expected to abstract over async, relying on the promise state?

From what I can tell, this change was merged and released without a passing build. Indicating that the project’s quality assurance process is little more than lip service. I’m not sure how you would track regressions if your tests are flakey to begin with.

I would bet on the source probably being gitlab-ci configurations

Are there any plans to address Bazel compatibility?

I understand that the Next philosophy is very monolithic but so far I’m having trouble getting it to play nice with build tooling.

Probably Kaggle competitions

Spring Boot with Webflux and any rx supporting libraries you can get your hands on

I believe we’re still trying to dig ourselves out of that particular hole since html days :)

How is it slow? [Citation needed]

The async model is easy to use so you get good performance before even optimize it. It comes out of the box with good json serialization/parsing, so that’s one less dependency. Not really sure where you’re coming from.

Then you end up with data fetches being tied to the rendering lifecycle in a way that makes modifying the mechanism painful

It's single threaded. You can usually stick the context in the request object itself.

I would vouch for IntelliJ. It's clean, customizable and nothing is hidden away

I would appreciate better naming on the variables. Some of this is hard to read through with single letter names

It’s probably rendering what would be “front page” given the same data but with today’s engine.

It would be interesting to see how everything is being cached for a particular day, though.

It's not the sharpness but the incredible amount of real estate you have. I can have documentation, a preview window and the code open at the same time in what would be their full screen resolution.

To anyone considering one, make sure it supports 60hz at full resolution, otherwise the choppyness makes it unusable.

This seems like a good example of what the OP is preaching:

Learn the box model[0], and you won't have to 'fiddle' anymore, you'll know why your elements are arranged the way they are.

Or, you could keep ploughing through permutations of bootstrap magic until you stumble at the correct implementation.

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Box_Mod...

A transaction log is too detailed and specific. Typically an event log lists actions from the business domain rather than what got affected. It should explain what happened, not how it happened.

This.

It makes Implementing CQRS in a single service really easy. GETs load the event log, replay and display the results while POSTs send a command that gets translated into an event. If it is valid it gets appended to the log. This approach is storage agnostic: It doesn’t matter how the log ultimately gets stored

It's fun to throw "A house of dust"[0] generated poems at it.

[0]https://nickm.com/memslam/a_house_of_dust.html

You could set up a CI server that watches commits, and then commit to a branch, have it deploy automatically.

For what it’s worth I agree with the person you’re replying to. The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.

I’m surprised you mentor, given all the hubris you have displyed on this thread.

You are supposed to modify and fit Agile into your specific process, not follow it dogmatically. It's literally the first thing on the manifesto: "Individuals and interactions over processes and tools". Change the process, or change the culture around this instead of blaming a broken process.

To add an example: At this company they have the concept of an IP (Innovation and Planning) sprint. This means that one sprint out of 5 we take to fix technical debt, add instrumentation, verify documentation. You should have some time carved out for mentoring.

At the very least, don't count the juniors in your capacity. This way you'll be able to handle their pace while keeping your velocity.

Exactly. The OP should learn the underlying technologies, instead of learning frameworks. They even admitted to not being willing to learn properly. At that point, how can you even make a fair comparison?

Most software is moving data around. All the abstractions you mentioned have a purpose. It makes sense to test each in isolation. For example, a controller whos’ service is a mocked implementation. You can test that your controller and its routes make the correct service calls without ever hitting a database.

About the documentation, maybe you’re the one to take initiative and spin up a wiki? Maybe you’re the person that consolidates logging into a reusable internal library?

Related to the topic, maybe this is not what you should be doing. There is good work out there, but as cliche as it sounds, you have to show passion for them to find you.

I’m finding the wix style guide very useful, because it provides baytle tested components for atomic elements (buttons, dropdowns, checkboxes) without imposing an overreaching design on you. (But still provides layout components)

https://github.com/wix/wix-style-react

Your second choice is just coupling it again. I've only seen few frameworks that let you render both HTML and json (Ruby on Rails).

You still have to map a model to HTML, regardless.

It's not that there's an additional layer, the rendering of the view was always there, just tightly coupled to fetching data from the DB.

It is now a better practice to create a BFF that can serve more clients than just browsers.

The answer here is to make the action easily reversible if possible.